On 01/23/2015 02:34 AM, Phillip Lord wrote: > Stefan Monnier writes: > >>> That's a problem with any lisp that provides a reader-macro facility. >>> The onus is on the authors of macro packages to create macros that work >>> well with the existing emacs-lisp-mode parser. >> >> That's a good point. >> >>>>> So I'm currently against addition of CL style reader macros. >>> Stefan, is emacs-lisp-mode support your only objection? >> >> Yes and no. No in the sense that I expect that introducing such reader >> macros will have consequences that go further than just "emacs-lisp-mode >> support". >> >> Maybe we could introduce a more limited form of reader macros. >> E.g. allow # and make the reader return >> >> (funcall (cdr (assq reader-macro-alist)) ) > > Would it not be possible to have the reader return a macro which could > do the cdr and assq at compile time and obviate the need for funcall? > This would be faster. It means that changes to reader-macro-alist > wouldn't be reflected in code till it was re-evaled. This paragraph is hard to parse, but ITYM that instead of literally calling funcall as Stefan described, the reader would mechanically transform _any_ construct of the form #LS, L being a letter and S being a sexp, into something like (expand-reader-macro 'L 'S). Maybe that could work, if the scoping rules (see below) were preserved. In any case, it's just an implementation detail. > My main concern with this as a proposal is that is a fairly > small namespace. There is a lot of possibility for pretty disasterous > clashes if this gets used in the wild. Of course. That's why we'd make each file register an association between letters and the macros to which they'd expand. Think of how XML namespaces map short local names to long global names. We'd make this mapping buffer-local, like lexical-binding.