help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Lexical vs. dynamic: small examples?


From: Drew Adams
Subject: RE: [External] : Re: Lexical vs. dynamic: small examples?
Date: Sun, 15 Aug 2021 21:57:06 +0000

> 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.

You might want to send your proposal/question along
via `M-x report-emacs-bug'.  That's the best way to
request enhancements, new features, and bug fixes.

You might also want to consider that Common Lisp,
designed by pretty much all of the wizards of Lisp
at the time, does what Emacs Lisp does.

With the exception that Emacs is not yet there all
the way: we have variable `lexical-binding', which,
yes, is a kludge indicating that we're straddling
two chairs.

IMHO, there is no confusion in the Common Lisp
world/community about `let' (or other constructs)
wrt lexical vs dynamic binding of a variable.

I think there's confusion in the Emacs world because
(1) Emacs long had only dynamic binding, (2) dynamic
binding is what Emacs users (but maybe less so Elisp
programmers) expect and make good use of when it comes
their own binding/setting of variables (e.g. options),
and (3) as noted above, Emacs is "entre deux chaises".

> 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?

Many/most languages have pretty much only lexical
binding.  But yes, an exception is made for top-level
definitions, in the sense that you can dynamically
issue another define/defun/defvar for the same thing.

There's _no_ scope for such definitions (though each
defines a scope _within_ it, for other bindings).
Each name defined with those constructs has indefinite
scope and dynamic extent (duration).

> If they can't, that issue (the issue of global variables)
> can be cancelled out from the discussion as well.

There's no "issue".  I mentioned defvar, defcustom,
defconst, defface, frame parameters, etc. as examples
of dynamically bound things that Emacs users are used
to.  The point was that dynamic binding is not exotic
or foreign for Emacs users.  But like Monsieur Jourdain,
they might well not be aware that they've been speaking
such prose all their Emacs lives.

The question was raised as to the usefulness of dynamic
binding for Emacs users.  I pointed to RMS's (excellent)
reasons for supporting it, and to the (dynamic) behavior
of those constructs, as what you (I, anyway) really want
in an interactive environment such as Emacs.

You can see that, when it comes to interaction with such
an environment, pretty much all languages have a dynamic
top level.  You can _imagine_ no defuns etc. but only a
big let, but you'll soon see that interacting with that
could be cumbersome.

Beyond such top-level dynamic binding of names, the real
advantages that RMS cites are what are important, and
they are more controversial.  Disparagement of "monkey
patching" is common.

And beyond the question of dynamic/lexical binding, there
are plenty of other "dirty" things to disparage in Lisp.

You can start with side effects.  And `quote' (which on
its own is enough to destroy referential transparency).

And you can continue with applicative-order, instead of
normal-order, evaluation.  That can lead to incorrect
results and to unnecessary infinite computation.

There are Lisps and other, more declarative, more purely
functional or logic languages, that do away with this or
that dirtiness.  And they're wonderful, and safe, and
more amenable to proof, and...  But maybe not so 
wonderful for an editing environment.

(You can even program in "pure", "academic" Lisp -
essentially lambda calculus with some built-in data
types.  That's used mainly for papers and proofs.)

> You also mention functions (`defun's) which are lexical in
> terms of the their formal parameters (= arguments, only
> theoretically, not applied). 

No idea what you mean by only theoretically.  A function
definition. whether by defun or as a lambda, is a binding
construct, just like let is, or an integral or sigma
expression is, or a logic expression with quantification
is.  You can define `forall' using lambda, just as you
can define let using lambda.

They're all abstractions - their purpose is to abstract.

(https://www.youtube.com/watch?v=-J_xL4IGhJA, minute 29:00)

As such, they all introduce variables and variable binding.

(There's no _need_ for variables actually.  Combinatory
logic is equivalent to lambda calculus, and it involves
no variables.  But for mere mortals, variables give us
some peace of mind and a map of the territory.)

Actual arguments to functions are bound lexically in Lisp
(modulo... depending on the approach).

There's a difference between how a function's parameters
are handled (which is lexically) and how the function
name itself is handled (dynamically, for a defun).

> Because the whole idea with functions is to modularize
> and encapsulate I find the concept of function dynamic
> scope a bit bizarre

Do you want to be able to redefine a function easily?

(defun foo (a) ...)
;; later...
(defun foo (a b c) ...)

> 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

See CLTL, flet and labels:

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node83.html

defun is convenient.  Even non-Emacsing lispers want
the convenience of a supple interactive environment.

(You have a similar situation with setq as with let,
BTW. It can assign to a lexical variable or a dynamic
one.)

> Then no one would have to mess with `lexical-binding',

Having to mess with the variable `lexical-binding' is
orthogonal.  As mentioned, that's only an Emacs thing,
and it's there only because we're between two chairs
at the moment (it's been a long moment).

<<attachment: winmail.dat>>


reply via email to

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