Yesterday, I discussed
here some issues with removing too many parentheses. Today I especially deal with the awful perversion of condp.
Apparently, removing parentheses from Lisp is a common pattern in modern Lisps. Arc seems to have taken the very same route, even though somewhat more extreme (e.g., let binds just one variable -- no parentheses needed --, with binds more than one and essentially uses clojure's let syntax). Anyway, back to condp...
condp takes a binary predicate, an expression, and a set of clauses.
Essentially instead of yesterday's example:
(cond
(instance? Integer x) :int
(instance? String x) :string)
we could have written:
(condp = (class x) String :string Integer :integer)
The first thing it is that, in my opinion, it may be rather easy to mistake the first pair (which semantically is the binary predicate and the expression) with the successive conditions. The second issue is that condp can have an odd number of arguments: the last one is the default. Now consider the pathological example
(condp
= (str x)
(str String) (str y)
(str Integer) (str z)
(str k))
And suppose that for some unfathomable reason is written like:
(condp =
(str x) (str String)
(str y) (str Integer)
(str z) (str k))
Ok... it is your mistake if you just don't format thing properly, but such a bug is much harder to spot than it should be. I understand that this example is extremely contrived.
The problem is that having to resort on basically enumerating arguments to understand what is their function (that is to say if they are in an even position they have a function, if they are not they have another, and if there is actually a last argument things are even different).
Things could be worse? They
are worse. I forgot to mention that condp clauses have both a binary form and a ternary form. In fact a clause instead of :
value expression
can be
value :>> unary-function
The first thing to notice is that enumerating arguments becomes even messier, and a special syntax is to be introduced. Counting becomes messier because you have to remember if you got an even or an odd number of ternary clauses, which changes the meaning of being in an odd or in an even position.
If we grouped things with parentheses, then it would be just a minor issue.
Once you are familiar with ternary clauses, you won't be surprised that
((fn [x] (condp = (keyword x) :a :>> :b :>> :<<)) :a)
evaluates to nil. I believe that this is an example of how some good features in a programming language conjure to create very counter-intuitive behaviour (I'm a big fan of the principle of least surprise).
Why? If we did not know of the ternary argument, one would thing that if (keyword x) is :a or :b then we get :>>, otherwise, we get :<<. This would be straightforward. Unfortunately[0], we do have the ternary clauses.
Ok, but this does not happen. :>> is magic. You cannot (easily) have a condp returning :>> [which is something I think would be perfectly legitimate, and in case you have to resort to an expression which evaluates to :>>, like (keyword ">>")].
I love magic in programming languages, but the magic leaning towards abstraction. The kind of magic which makes complex things easy, not the kind of magic which essentially introduces a special case for something of dubious value.
So, back to the expression... :a equals to :a, so that condition is chosen. But :>> is magic. Consequently :>> is not returned. Rather (:b :a) is evaluated. But remember, a keyword may be used to test inclusion; this is a nice programming language feature in many situation, but here it plays awfully bad with the other parts. So we are basically asking... is :b in :a? And the answer is nil.
By the way, this does the right thing:
((fn [x] (condp = (keyword x) :a (keyword ">>") :b (keyword ">>") :<<)) :a)
If you are wondering whether parentheses would have fixe the issue... yes they would.
((fn [x] (condp = (keyword x) (:a :>> :b) (:>> :<<))) :a)
is clearly and immediately distinguishable from:
((fn [x] (condp = (keyword x) (:a :>>) (:b :>>) (default :<<))) :a)
Notes
- It is not that I don't like the idea behind ternary clauses: I just believe that they should be in a separate conditional form. And if you just don't need a function for some of the clauses, clojure has an extremely neat syntax and you can just write #(do % val) or (fn [_] val); I believe that the latter is clearer.
Clojure, Programming, Lisp, Common Lisp, Scheme
2 comments:
Thanks for sharing this. Made me think about my own macros that are relying on the arguments paired up instead of external parentheses.
You're welcome!
Post a Comment