From: Drew Adams <drew.adams@oracle.com>
To: Emanuel Berg <incal@dataswamp.org>,
"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: RE: [External] : Re: Printing alist pairs to a dedicated buffur
Date: Fri, 26 Apr 2024 15:55:37 +0000 [thread overview]
Message-ID: <SJ0PR10MB548829B90A40C22901D1B803F3162@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87msph9ehc.fsf@dataswamp.org>
> > Dynamic binding is still the default in Elisp. The doc is
> > correct about that.
>
> Yes, but isn't that a practical measure so that legacy code
> won't break?
Yes. Emacs isn't "Move fast & break things",
because it cares about its users. Users are
Emacs.
Legacy code - of which there's a _ton_, likely
multiple times the code delivered with Emacs.
Including code used in industry and government.
Don't just think "my code". Most Emacs users
don't frequent mailing lists or other forums
about Emacs. And not all Elisp code is by or
even for individual users.
And besides legacy code: legacy _habits_,
i.e., people. In a word, history.
___
I said it before: what Emacs is now aiming for
wrt lexical binding of variables by default,
i.e., except for those declared "special", is
what Common Lisp has had from the start - 40
years ago.
And CL was the result of long discussions by
most of the world's Lisp experts, familiar
with the history of Lisp and the existing
Lisp implementations.
(It's true that U.S. experts participated
more than Europeans or others, alas. The
world was even more parochial back then
than it is now.)
This is by way of saying that there's nothing
new about the behavior of lexical and dynamic
binding (and about their coexistance) in a
programming language or environment. The
gotchas and foibles were well known. Scheme
existed, for example, and its designers were
among those who designed Common Lisp.
Likewise, the problems with applicative-order
evaluation (eval all args, before evaling the
function body after their substitution) were
well known. (Google "funarg problem".)
E.g., Lisp uses applicative order, as opposed
to normal order, which is used by Haskell etc.
Real (i.e., pure) lazy functional programming
was also already a thing back then, though
not so widely known.
Elisp will get to where Common Lisp has been,
wrt lexical & dynamic binding. But it's not
there yet.
Keep in mind that Elisp is not only a general
programming language (but it's also that).
It's an interactive editing (and A, B, C,...)
environment. Know not only the advantages of
lexical binding, in general, but also those
of dynamic binding - and particularly in an
interactive, editing context.
For that, I recommend RMS's points about why
dynamic binding is _useful_ for Emacs users:
https://www.gnu.org/software/emacs/emacs-paper.html#SEC15
And my point here was also to remind you that
binding is not only about variables, and you
cannot practically use Emacs without taking
advantage of its dynamic binding of options,
named functions, faces, and on and on and on.
You might not think about that. Imagine, if
you had to pass your preferred value of some
user option or face explicitly as an argument
into thousands of functions, instead of it
being global. _All_ user options. The very
notion of a user option disappears.
I'll say it again:
Let us know, when you use lexical binding
for _all_ your defuns, as well as for
defface and all the rest. ;-)
Face it:
Global definitions and dynamic binding are
your friends, just as much as locally-scoped
definitions and lexical binding. You just
need to know which friend to call in any
given context, for favor or fun.
next prev parent reply other threads:[~2024-04-26 15:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 12:57 Printing alist pairs to a dedicated buffur Heime
2024-04-19 13:24 ` Manuel Giraud via Users list for the GNU Emacs text editor
2024-04-19 19:26 ` Heime
2024-04-19 19:42 ` Heime
2024-04-20 9:55 ` Manuel Giraud via Users list for the GNU Emacs text editor
2024-04-20 10:08 ` Emanuel Berg
2024-04-25 11:13 ` Heime
2024-04-26 0:27 ` Emanuel Berg
2024-04-25 15:55 ` [External] : " Drew Adams
2024-04-25 16:18 ` Heime
2024-04-25 22:43 ` Emanuel Berg
2024-04-25 22:29 ` Emanuel Berg
2024-04-25 23:38 ` Drew Adams
2024-04-26 0:03 ` Emanuel Berg
2024-04-26 15:55 ` Drew Adams [this message]
2024-04-26 16:57 ` Heime
2024-04-26 17:27 ` Yuri Khan
2024-04-27 22:20 ` Heime
2024-04-26 0:41 ` Emanuel Berg
2024-04-26 1:08 ` Emanuel Berg
2024-04-20 16:37 ` Heime
2024-04-20 17:23 ` Heime
2024-04-20 20:48 ` Yuri Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB548829B90A40C22901D1B803F3162@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=incal@dataswamp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).