[Top][All Lists]

[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.


reply via email to

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