From: Heime <heimeborgia@protonmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 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 16:57:05 +0000 [thread overview]
Message-ID: <0jOwJ1JGd7GPBxiL3BuPtprxSM5D4xW8PgySDUa_0MCvTTjrr6Id3vGol5CLLhXfFya5WJ0HGiJHnMqcD2bcKgSMxdRd3NEH4V3o8S2-zCk=@protonmail.com> (raw)
In-Reply-To: <SJ0PR10MB548829B90A40C22901D1B803F3162@SJ0PR10MB5488.namprd10.prod.outlook.com>
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 !!!
next prev parent reply other threads:[~2024-04-26 16:57 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
2024-04-26 16:57 ` Heime [this message]
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='0jOwJ1JGd7GPBxiL3BuPtprxSM5D4xW8PgySDUa_0MCvTTjrr6Id3vGol5CLLhXfFya5WJ0HGiJHnMqcD2bcKgSMxdRd3NEH4V3o8S2-zCk=@protonmail.com' \
--to=heimeborgia@protonmail.com \
--cc=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).