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: Stefan Monnier
Subject: Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal
Date: Thu, 22 Jan 2015 11:44:34 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>     #(foo bar) should translate to (short-lambda (foo bar))

Hmm...

Not completely sure where I stand on this.
A few notes:
- I like the generality of CL reader macros.
- But extending elisp-mode to understand what's going on (and "do the
  right thing") with each new reader macro is not easy.
  So I'm currently against addition of CL style reader macros.
  In this sense your #(...) proposal is not too bad because the new
  syntax is largely compatible with what we have already (e.g. the (...)
  part is parsed in the normal way).
- In "(lambda (x) (foo bar))" the main problem for me is the visual length,
  so I use pretty-symbols-mode to make it look like (λ (x) (foo bar)).
  #(foo bar) is still shorter, tho, so I like this.
- I'm a functional programmer at heart, so I like making higher-order
  functions more accessible.
- But the current Elisp implementation is not good at handling function
  calls efficiently, so offering a very short syntax like #(foo bar) is
  kind of lying to the programmer.
- Elisp has the particularity that it's used by a very large number of
  people who don't actually know/understand the language, and will never
  really learn it.  OT1H (add-hook 'foo-mode-hook #(define-key toto titi))
  looks simpler, but OTOH having more equivalent syntaxes leads to more
  confusion for beginners.

So I'm not dead set against it, but I'm not really sure it'd be an
improvement either.

Of course, your proposal has 2 parts:
- the #(...) reader syntax.
- the new macro.
They work together but can also be used separately.  E.g. we could have
just the macro and write things like (mapcar (code (+ % 1)) list).
And we could have just the #(...) syntax and give it any meaning we like.


        Stefan



reply via email to

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