From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: [External] : Re: Lexical vs. dynamic: small examples?
Date: Sun, 15 Aug 2021 20:49:31 +0200 [thread overview]
Message-ID: <87wnompmpw.fsf@zoho.eu> (raw)
In-Reply-To: SJ0PR10MB54881113674427B7FC5311F0F3FC9@SJ0PR10MB5488.namprd10.prod.outlook.com
Drew Adams wrote:
>> So I wonder again, why not just have two let, one
>> "let-stay" (the variables stay so has to be used and/or
>> passed explicitely), and "let-follow" (the variables follow
>> everywhere the code goes within the let form).
>
> Sorry, I don't follow you. It's not clear to me what you're
> proposing or (more importantly) what problem you think you
> have with the designed behavior.
`let' does two different things, that is confusing, and it is
usually explained with theory - and the terms are confusing as
well - and to set what usage one gets one has to mess with
a variable - what kind of style is that? Just imagine, instead
of `+', `-', etc we would have just one function, "do-math"
which would look for for the value of "operator" to determine
what to do...
So the proposal/question is, instead one could have `let'
_always_ be lexical, and one "with-variables-as" which would
be what is now called "dynamic binding" with let.
"Dynamic" is something that changes over time, but TBH I don't
really see the static/dynamic aspect or difference here?
But OK, for the sake of the discussion, let's call them "letl"
(the lexical one) and "letd" (the dynamic one).
If one did it like that, for practical purposes, the whole
lexical/static vs special/dynamic binding or scope (and
extent) could be dropped, one would just write one docstring
for "letl" and one for "letd"!
(Let's not bring in the issue of nonlocal exits like
exceptions and continuations because if they are indeed
"exceptions" they can be whatever.)
OK, that's let, you also mention global variables, they are
always special/dynamic. However I don't see how that could or
should be done in any other way, how can they be lexical?
If they can't, that issue (the issue of global variables) can
be cancelled out from the discussion as well.
You also mention functions (`defun's) which are lexical in
terms of the their formal parameters (= arguments, only
theoretically, not applied). Because the whole idea with
functions is to modularize and encapsulate I find the concept
of function dynamic scope a bit bizarre, so in a way this
issue (defuns) could be cancelled out as well. But sure, if
someone want them to be dynamic, then why don't we do the same
as I proposed for `let' (which was `let' = "letl", lexical;
and "letd", dynamic), i.e. we would have
`defun' = "defunl", lexical; and
"defund", dynamic
?
Then no one would have to mess with `lexical-binding', in any
way (especially not that commented way that reminds me of
a C preprocessor or something), one would just use whatever
one wanted and to explain it to newcomers one would just refer
to the docstrings, no need for CS theory or anything (not
saying it should be forbidden or anything) but for practical
purposes it wouldn't be needed. Everyone would see in the code
- ah, here it is used like that, there it is used the
other way.
--
underground experts united
https://dataswamp.org/~incal
next prev parent reply other threads:[~2021-08-15 18:49 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-14 3:34 Lexical vs. dynamic: small examples? Eduardo Ochs
2021-08-14 3:56 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 4:12 ` Eduardo Ochs
2021-08-14 7:35 ` tomas
2021-08-14 16:00 ` Eduardo Ochs
2021-08-14 19:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 20:42 ` tomas
2021-08-14 19:31 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 20:31 ` tomas
2021-08-14 21:26 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 21:29 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 13:35 ` [External] : " Drew Adams
2021-08-14 16:15 ` Eduardo Ochs
2021-08-14 19:00 ` Gregory Heytings
2021-08-14 20:16 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 20:23 ` Gregory Heytings
2021-08-14 21:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 21:13 ` tomas
2021-08-14 21:28 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14 20:41 ` tomas
2021-08-15 0:29 ` [External] : " Drew Adams
2021-08-15 0:52 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 1:04 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 1:18 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 4:44 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 5:02 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 15:49 ` Drew Adams
2021-08-15 18:49 ` Emanuel Berg via Users list for the GNU Emacs text editor [this message]
2021-08-15 21:55 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-15 22:04 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 21:57 ` Drew Adams
2021-08-15 22:20 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 22:54 ` Drew Adams
2021-08-15 23:16 ` Drew Adams
2022-01-09 7:08 ` Jean Louis
2022-01-09 15:03 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 23:42 ` Arthur Miller
2021-08-15 22:02 ` Lars Ingebrigtsen
2021-08-15 22:22 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 22:44 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-21 3:38 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-24 2:08 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-25 23:34 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-25 23:40 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-26 0:10 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-26 0:44 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-26 17:01 ` FW: " Drew Adams
2021-08-26 23:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-25 23:46 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-25 23:47 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-26 0:57 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-28 1:36 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-28 1:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 22:44 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 22:58 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-15 23:13 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 23:56 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-16 0:43 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-15 15:42 ` FW: " Drew Adams
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=87wnompmpw.fsf@zoho.eu \
--to=help-gnu-emacs@gnu.org \
--cc=moasenwood@zoho.eu \
/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).