[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : Re: Printing alist pairs to a dedicated buffur
From: |
Heime |
Subject: |
RE: [External] : Re: Printing alist pairs to a dedicated buffur |
Date: |
Fri, 26 Apr 2024 16:57:05 +0000 |
On Saturday, April 27th, 2024 at 3:55 AM, Drew Adams <drew.adams@oracle.com>
wrote:
> > > 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.
In summary, all the talk criticising my use of Global
definitions was nonsense from the start. Then one wonders
how developers are not invited for parties !!!
- Re: Printing alist pairs to a dedicated buffur, (continued)
- RE: [External] : Re: Printing alist pairs to a dedicated buffur, Drew Adams, 2024/04/25
- RE: [External] : Re: Printing alist pairs to a dedicated buffur, Heime, 2024/04/25
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Emanuel Berg, 2024/04/25
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Emanuel Berg, 2024/04/25
- RE: [External] : Re: Printing alist pairs to a dedicated buffur, Drew Adams, 2024/04/25
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Emanuel Berg, 2024/04/26
- RE: [External] : Re: Printing alist pairs to a dedicated buffur, Drew Adams, 2024/04/26
- RE: [External] : Re: Printing alist pairs to a dedicated buffur,
Heime <=
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Yuri Khan, 2024/04/26
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Heime, 2024/04/27
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Emanuel Berg, 2024/04/26
- Re: [External] : Re: Printing alist pairs to a dedicated buffur, Emanuel Berg, 2024/04/26