top | item 7174980

(no title)

Mikera | 12 years ago

IMHO Clojure's omission of reader macros is sensible: it prevents proliferation of custom syntax, which makes it harder for a human to read code and reason about reader behaviour. The Clojure reader also already has its own literal syntax for vectors and maps [] and {} (which eliminates the most common use cases for reader macros).

If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?

Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.

So Clojure rejects the former (unnecessary syntax sugar, potential for confusion, dubious value of reader proliferation) and accepts the latter (additional semantic power, proven utility). I personally think that's a good trade-off. YMMV of course.

Of course, there's nothing stopping you from implementing a custom reader in Clojure if you really want reader macros. So far, nobody (to my knowledge) seems to have cared enough to do this.

NOTE: I'm not bashing Common Lisp: just pointing out that language design has real trade-offs. For me, Clojure gets the majority of these design decisions right. For others, maybe reader macros are an essential feature and Clojure therefore doesn't work. No problem, use whatever works for you.

discuss

order

lispm|12 years ago

The reader is first of all there to extend s-expression syntax to new datatypes - not for arbitrary syntax.

Btw., vectors are written as #(1 2 3) in Common Lisp.

Thus if I as a developer want to serialize my data structure to an s-expression, I can use reader macros.

New data type syntaxes does not make code much harder to read.

> If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?

Sure, Common Lisp has a standard reader. An extensible one.

> Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.

Custom control structures don't make the code harder to understand? Strange.

> For me, Clojure gets the majority of these design decisions right.

For me many of these Clojure design decisions look arbitrary and some I find just wrong. But that's just me.