Archive for December, 2009

I would like to add just a few more arguments regarding the issue of notation.

There is a certain austerity tradition coming from the CS community (at least from the BEST part of it). Most people see syntactic sugar as a waste of time and energy. Furthermore everything is just trees and a linear representation with the root at the head is just fine to represent trees. Lisp embodies this tradition to the full. And for the most part is a great tradition.

This is all fine, and I would understand the defensiveness considered that we live in a world polluted with overly complex languages which just bring problems and no advantages to compensate.

But some level of syntactic sugar is important for humans. And while meta-programming is nice, I suppose most programming languages are still used by human programmers ;) .

It would suggest to have a look at the literature on human cognition, namely the strategies used to read text: it is messy. But I prefer to go in a different direction. I just want to expose how some subtle representation issues might have a massive impact: Have you ever tried to do basic arithmetic with roman numerals? Have a look here, namely “How can I use Roman numerals to do arithmetic problems?”. While this is a different problem, it serves to emphasize that representation matters in the most strangest ways.

Even if it doesn’t, humans are a conservative species, they are not ready to change everything at the same time. Having a to jump to imperative+heteroiconic+infix to functional+homoiconic+prefix is too much. Lisp derived languages loose potential to attract more people. And in this case is is really worth it? Is it really THAT IMPORTANT to be prefixed? Is that the main conceptual selling point of Lisp?

But most importantly there are solutions that are not dirty:.

First nobody is forcing infix notation, one can have both at the same time (check Prolog :- op – you can do BOTH +(1 2) and 1+2).

Second hard-coding operators is not necessary at all: again check the Prolog suggestion. You can have all infix operators that you want (including none)

It is easy to conceptualize a superset of Lisp with infix notation and ZERO INITIAL infix operators.

If I can shout something is this: Check Prolog’s :- op ! Simple, elegant. And fully coherent with the Lisp philosophy at its core.

Social network sharing
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • DZone
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • LinkedIn
  • connotea
  • FriendFeed
  • Twitter
  • Yahoo! Bookmarks

Tim Bray presented his 11 Theses on Clojure. Thesis number 2 is “Being a Lisp Is a Handicap”. This argument has actually 3 parts: the Lisp-parenthesis syntax, which he finds bad. Homoiconicity (he finds good) and macros (again good).

I would like to discuss a bit the first (syntax) and the last (macros). The macro part discussed somewhere in the future. For now I would like to concentrate on syntax.

Lisp syntax is strange for most humans, we simply do not write (+ (* 2 3) (/ 4 2)). Lisp proposers are probably aware that this will not be very popular, as people are used to something completely different. It is not only different but is also very uneconomical to both read and write: 2*3 + 4/2 is arguably easier to read. One can even make some intuitive declarative things. Notice that I’ve written 2*3 (no space around *) but 2*3 + 4*2 (spaces around +). This allows to give queues to readers about the precedence of operators. You can say that these issues are just simple and ridiculous syntactic sugar. Well, it seems that Homo sapiens has evolved to appreciate it. And I don’t really see a reason not to accommodate this requirement.

Yes, I read you already: infix syntax forces hard-coding of operators and precedences (e.g. + precedes *) . Makes parsing much more complex (there goes the beautifully simple Lisp parser out of the window) and in fact forcing a certain structure with hard-coded operators.

Well… no.

Take a look at Prolog op built-in. :- op allows you to define operator precedence and association rules. So the parser is really not much complex: it starts with a simple, uber-flexible, blank slate which you can fill in.

So, for (- 4 3 2) you can say – is an infix operator with first argument with precedence over the second (i.e. (4 – 3) – 2) and, voila, you can write 4 – 3 – 2. No need for hard-coded operators, all dynamically defined. You could, maybe for sadistic reasons, change the argument precedence so 4 – 3 – 2 would become 4 – (3 – 2). The flexibility is there.

You can also state that + and – have higher precedence than * and /. So that 2*3 + 2 is interpreted as (+ (* 2 3) 2). Again, you can change the precedence rules.

Ah… and you can have operators that are atoms (alphanumeric symbols). In Prolog you can say “X is 3 +2″. “is” is an operator. You can redefine operator rules, define new operators.

Operators are nothing more than a set of syntactic sugar rules to convert a more intuitive representation to another. But they really make things much more pleasant and humane.

I would imagine that adding this to Clojure would be DEAD EASY, by the way.

Regarding the issues about macros, I will leave it for another post.

Social network sharing
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • DZone
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • LinkedIn
  • connotea
  • FriendFeed
  • Twitter
  • Yahoo! Bookmarks