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: Sat, 16 May 2020 21:51:05 +0300
User-agent: mu4e 0.9.18; emacs 28.0.50

On 2020-05-15 06:24 +03, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> The choice between the syntax ($ (+ $1 $2))
> and the syntax #(+ %1 %2), I think it is a small difference.
> If one is ok, the other is ok.

Sure.

> The # syntax has the small advantage of being a little shorter.
>
> The $ syntax can be implemented now with a macro -- but if we want this
> feature, I see no reason to hesitate to do implement it in the reader,
> no need to use a macro.  It would not be a lot of work to do that.

I think the main point which can help pick one over the other is whether
or not the reader implementation can reliably and easily be backported.
AFAIU Emacs can’t do reader macros, so in order to implement this in the
reader we’d have to change stuff in C which means the feature is limited
to future releases. A Lisp macro (with whatever syntax, I’m not really
partial to $, just that it’s short and, reserved as an operator, and is
mildly similar to how most Unix shells do it) OTOH can be backported
easily via an ‘fboundp’ check or (less desirably) a dependency on an
obsoleted package we might introduce to ELPA (would require an Emacs
version check to reliably control), making it easier to adopt especially
in packages.

This is especially relevant for those who use Emacs from their distro
repos who won’t be on board with latest releases possibly for years, and
for most popular packages who still support at least Emacs 24. A reader
implementation would confine this to the init.el’s of those who (like
me) follow the development branch for years to come, which is
unnecessarily limiting given we have the luxury of not needing to change
the parser.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427



reply via email to

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