emacs-devel
[Top][All Lists]
Advanced

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

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]


From: Göktuğ Kayaalp
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Tue, 19 May 2020 02:24:07 +0300
User-agent: mu4e 0.9.18; emacs 28.0.50

On 2020-05-18 07:42 +03, Stefan Monnier wrote:
> FWIW, I'm not too fond of such shorthand syntax.  The benefit is not
> very high and it makes the language that much more difficult to learn
> for newcomers.
>
> For a programming language like Closure, it might make sense, since
> most/all people writing Closure programs are actual programmers that
> have to be proficient in Clojure.  But Elisp lambdas are very common in
> .emacs files, so this additional complexity will be exposed to some of
> our users who aren't programmers or aren't proficient in Elisp.

I don’t think it’s that much of additional complexity given many
popular programming languages have multiple ways to define one off
closures: Python (inline def vs. lambda), JavaScript, Ruby, even C++
these days AFAIU.

And, as someone else mentioned, the $ syntax has the nice effect that
C-h f can be enough.

> If we want to shorten anonymous functions we could start with something
> like (λ (x) (f x 1)), which you can get with
> prettify-symbols-mode already.

dollar.el and the reader modifications do more than just shortening the
keywords tho: it allows to define arguments whose names don’t really
matter.  Which is why these syntactic patterns go well with map-reduce
programs and when passing :key, :test, and simple callback arguments.

I’d say random one letter names or one off long names may create more
confusion than symbols that boil down to nth arg.

          -gk.



reply via email to

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