Re: Are there any problems with lexical-let or other cl-macros???

[Helmut Eller]

* LanX [2010-06-01 16:20+0200] writes:

>> Esthetically, but the implementation is not efficient, and cannot be
>> since the emacs VM (which is a very high level lisp VM) doesn't
>> provide a way to implement lexical binding at all AFAIK (well perhaps
>> using a lisp vector and mapping variables to offsets, but this
>> probably would not be more efficient either).
>>
>
> So it's only a performance issue? Isn't Elisp supposed to be slow
> anyway?
>
> he also writes
>
> "(elisp...) at the very least, it should support reader macros."
>
> could you please explain whats missing in defmacro?
>
> I always thought they are expanded when the parser reads the code to
> be compiled... or what is the definition of "reader macro" (couldn't
> google good explanations and the elisp info has only one mention at
> "16.5 Evaluation During Compilation")

"Reader macros" are not the same as macros defined with defmacro.  In
Common Lisp the reader ie. the function that turns text into
s-expressions can be customized.  A typical reader macro is #' which is
responsible for converting #'foo to (function foo).  Emacs' reader is
not customizable.  Even ' is which turns 'foo into (quote foo) is a
reader macro.

Traditionally reader macros start with # and some are standard, e.g. #(
is for reading vectors and #s for reading structures.  But in principle
every character can have a reader macro e.g. { could be used to parse
hash tables or #/ to parse regexps etc.

A reader macro has access to the text input stream and can construct
arbitrary objects at read time.  The compiler takes the objects returned
by the reader and the compiler expands the macros defined with defmacro.

Helmut