Clojure has this handy way to view a function's definition in REPL.
Is there one in Elixir REPL ?
No, there isn't a convenient way yet.
Well, I'm going to post this as an answer, even though it's not the same as "source". In IEX, you can type h function_name to see the documentation for function_name. It's basically Clojure REPL's doc feature. So far, in Elixir, this is good enough for most cases where I want source.
Related
I have just recently started to learn some clojure and in order to make something like types (more like contracts) for validations etc, the go-to solution is a library named schema.
Recently I learned that clojure 1.9 however will have something similar named clojure.spec
Can anyone please tell me the differences between them?
When should I use one or the other, pros and cons, etc?
Eric Normand did this comparison, but as already pointed out you should definitely check the rationale, and there is also the guide and a podcast where Rich Hickey talks abouts clojure.spec.
The spec rationale is quite in-depth, I would suggest reading it: https://clojure.org/about/spec after that feel free to compare it with any other library you may be considering.
I'm reading some Clojure code at the moment that has a bunch of uninitialised values as nil for a numeric value in a record that gets passed around.
Now lots of the Clojure libraries treat this as idiomatic. Which means that it is an accepted convention.
But it also leads to NullPointerException, because not all the Clojure core functions can handle a nil as input. (Nor should they).
Other languages have the concept of Maybe or Option to proxy the value in the event that it is null, as a way of mitigating the NullPointerException risk. This is possible in Clojure - but not very common.
You can do some tricks with fnil but it doesn't solve every problem.
Another alternative is simply to set the uninitialised value to a symbol like :empty-value to force the user to handle this scenario explicitly in all the handling code. But this isn't really a big step-up from nil - because you don't really discover all the scenarios (in other people's code) until run-time.
My question is: Is there an idiomatic alternative to nil-punning in Clojure?
Not sure if you've read this lispcast post on nil-punning, but I do think it makes a pretty good case for why it's idiomatic and covers various important considerations that I didn't see mentioned in those other SO questions.
Basically, nil is a first-class thing in clojure. Despite its inherent conventional meaning, it is a proper value, and can be treated as such in many contexts, and in a context-dependent way. This makes it more flexible and powerful than null in the host language.
For example, something like this won't even compile in java:
if(null) {
....
}
Where as in clojure, (if nil ...) will work just fine. So there are many situations where you can use nil safely. I'm yet to see a java codebase that isn't littered with code like if(foo != null) { ... everywhere. Perhaps java 8's Optional will change this.
I think where you can run into issues quite easily is in java interop scenarios where you are dealing with actual nulls. A good clojure wrapper library can also help shield you from this in many cases, and its one good reason to prefer one over direct java interop where possible.
In light of this, you may want to re-consider fighting this current. But since you are asking about alternatives, here's one I think is great: prismatic's schema. Schema has a Maybe schema (and many other useful ones as well), and it works quite nicely in many scenarios. The library is quite popular and I have used it with success. FWIW, it is recommended in the recent clojure applied book.
Is there an idiomatic alternative to nil-punning in Clojure?
No. As leeor explains, nil-punning is idiomatic. But it's not as prevalent as in Common Lisp, where (I'm told) an empty list equates to nil.
Clojure used to work this way, but the CL functions that deal with lists correspond to Clojure functions that deal with sequences in general. And these sequences may be lazy, so there is a premium on unifying lazy sequences with others, so that any laziness can be preserved. I think this evolution happened about Clojure 1.2. Rich described it in detail here.
If you want option/maybe types, take a look at the core.typed library. In contrast to Prismatic Schema, this operates at compile time.
G'day gurus,
I've written some code that leverages a Java library that makes uses of the visitor pattern. What I'd like is to hide all the messy details of the visitor etc. behind a single Clojure function that takes the input parameter(s) and returns a simple data structure containing all of the state derived by the visitor.
The trick is that there are multiple "visitXXX" callbacks on the Java side and there's no easy way to return state back out of them (Java, being Java, assumes any state that gets built up by the various visitors is stored in instance variables).
What I've done (and which seems to work great, fwiw) is define an atom in a let block, and have each of my visitor functions swap! the atom with an updated value when they're called by the Java visitation code. I then return the deref'ed atom out the end of the main "driver" function, after the Java visitor completes.
My question is: is this an appropriate usage of an atom? If not, is there a more idiomatic way to do this?
If anyone's interested, the code in question is here.
Disclaimer: I'm still a Clojure n00b so that code is probably hideous to the more discerning eye. Comments / feedback / critiques welcome!
Thanks in advance!
Your approach using an atom is fine and looks good and clojurish.
If you are looking for other approaches as well; since you can split your problem into some code that will produce and answer (your visitor) and some other code that will need the answer when it is available, Clojure's promise and deliver functions may be well suited.
If you create the promises in the let block, then have the visitor deliver the results to the promise.
I am writing a Clojure program which need to generate a Java source. Is there a good idiomatic way/template engine for that.
In Java world I would probably use Velocity or Freemarker. I know I can still use them from Clojure, but wondering if there is better way.
Probably you can take a look at Rythm template engine, which is much faster than Freemarker and Velocity, also much easier to use.
Document could be found at http://www.playframework.org/modules/rythm-1.0.0-20121210/home
Note although the document is for play-rythm module, the most part of it also apply to pure rythm environment
I've been using Clojure with StringTemplate for the purpose you describe for quite some time now with good results. I 've also defined a helpful set of macros that make the invocation of the StringTemplate renderers from Clojure a breeze. StringTemplate is established, solid and used for heavy-weight compilers so it can't fail you. On simplicity / speed or other trade-offs I cannot comment.
I know monads are available in clojure, but has anyone verified that they work in clojurescript?
Monads work in clojurescript. The only thing is the way you reference macros in clojurescript [1].
What I did is copy all tools/macro.clj and all the monads.clj code into a big file which I then reference from clojurescript.
It's perhaps not the most elegant way but it works.
You can find the file in https://github.com/cotarmanach/clojurescript-monad-macros
(I copy it in my project and change the namespace to be the one of my project)
[1] See https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure
ClojureScript's macros are written in Clojure, and are referenced via
the require-macros keyword in namespace declarations:
(ns my.namespace (:require-macros [my.macros :as my])) The :as
prefix selector is required in :require-macros. One point of note is
that the code generated by ClojureScript macros must target the
capabilities in ClojureScript.
Monads, the Functional programming method, only require a language with higher order functions and closures. You would need a ClojureScript monad library. Or you can go ahead and write your ClojureScript in a monadic style
EDIT: by "monadic style" I was referring to writing and composing functions that take and return monadic values and implement the three monad laws. There are too many people better qualified to explain monads than I, so I will just link to one of my personal favorite videos on monads.
There is a great port of the Fluokitten Library to ClojureScript by Chris Zheng: https://github.com/purnam/brahmin
Chris has a great post reflecting on Monads as a result of this.
The cats library for Category Theory is also good https://funcool.github.io/cats/latest/
Monads in ClojureScript is alive and well.