On Wed, Dec 09, 2009 at 02:35:24PM -0800, Joost wrote:
> On 9 dec, 17:03, Jeff Dik <s45...@gmail.com> wrote:
> > The part "Running code at read-time lets users reprogram Lisp's
> > syntax" caught my attention.  Is this talking about reader macros?  I
> > believe I read that clojure doesn't have reader macros, so would it be
> > more accurate to say "The whole language is there, _most_ of the
> > time"?
> 
> Clojure doesn't have user-implementable reader macros, but neither
> does emacs lisp. Reader macros are nice when you need to embed a
> significantly different looking kind of language - that's why clojure
> implements regular expressions as a reader macro instead of a function
> on a string; you'd have to doubly escape every backslash otherwise.
> But they're mostly "only" a way to provide syntactic sugar.
> 
> I think what Paul is +mainly+ talking about in terms of "syntax" is
> just plain ordinary macros that can implement short-circuiting and
> different evalution strategies for readable data, so that you can
> implement things like (unless ...) yourself, with no (significant)
> overhead compared to the built in (if), but you'll have to keep to the
> basic reader constructs (but not evalution rules). This has the
> advantage of keeping the language simpler to parse and readble for
> humans too.
> 
> The other part of the "always there" is that you can use whatever is
> already compiled/parsed to construct new macros, so you can build
> macros on top of each other, and on top of a mix of macros and (user-
> defined) functions instead of being restricted to the "traditional"
> sparseness of C preprocessor macros.

Thanks to everyone who replied to my question!  I had not realized that
clojure had built-in reader macros (which I should have realized from
section 2.2 "Reader Macros" of "Programming Clojure").  The day I
wrote the original email was the first day I think I actually realized
what reader macros do, which, in retrospect, should have been obvious
from their name.  Just another example of Lisp blowing my mind.

I wasn't advocating user-creatable reader macros or bemoaning the lack
of them in Clojure.  I trust Rich Hickey's judgment :-) He's
much smarter than me and is an excellent language designer[1] (IMHO).

Still, I may have to play with user-creatable reader macros in Scheme
or Common Lisp.  I can see how they could make code harder to read if
a lot of people used them, but wonder if people standardized on some
of them, if they might make it more easier to write code for certain
fields (e.g. matrix math).  I think Graham Fawcett's idea of having an
experimental branch of Clojure that allowed user-creatable reader
macros is a good idea and wish I was smart enough to do it :-)

Thanks,
Jeff

[1]: Side note.  I think one of the best illustration's of Rich's
genius[2] is that he was able to combine Lisp, Java, functional
programming, and concurrency into such a beautiful language, as
opposed to Bjarne Stroustrup (also extremely smart) taking C and
adding OOP, etc, and making a lot of very reasonable decisions, and
still coming up with a monstrosity.

[2]: Side note on the side note.  Another example of Rich's genius are
the changes to Clojure for version 1.1.

> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to