emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function liter


From: Daniel Colascione
Subject: Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal
Date: Fri, 23 Jan 2015 03:50:52 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 01/23/2015 02:34 AM, Phillip Lord wrote:
> Stefan Monnier <address@hidden> 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 #<letter><sexp> and make the reader return
>>
>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
> 
> 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 <letter> 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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]