Does anyone know when lexical scope started appearing in Lisp? Not
counting Scheme, did it exist in predecessors of Common Lisp? Was it
used much? Is it really true that Common Lisp had both lexical and
dynamic scope in order to support older code that was written relying on
dynamic scope and was too hard to convert?

Thanks. This topic came up in the Forth group.

On 3/15/2024 12:55 PM, Paul Rubin wrote:
> Does anyone know when lexical scope started appearing in Lisp? Not
> counting Scheme, did it exist in predecessors of Common Lisp? Was it
> used much? Is it really true that Common Lisp had both lexical and
> dynamic scope in order to support older code that was written relying on
> dynamic scope and was too hard to convert?
>
> Thanks. This topic came up in the Forth group.

I'll comment on only a part of your questions, namely whether CL had
dynamic scope only for compatibility? The view that I and many others
had was that compatibility made it a must AND:

Once you have had the programming convenience of using dynamic scope,
you would miss it terribly in a lexical-only language, or worse, in
something like the old FORTRAN assembler-level scope. Another argument
that I have not seen debated but may be significant is that the CL Error
System -- the programming primitives and error class structures don't
make a lot of sense in lexical only. The error mechanisms like catch
have meanings that include phrases such as "while executing this. I'm
available to handle that".

The availability of such fine grained control structures makes many
typical Lisp non-hierarchical reasoning* programs possible. I believe
that the early and middle AI communities were drawn to Lisp-like
development tools because of these possibilities.

* By non-hierarchical reasoning, I'm thinking of Simon's "almost
decomposable systems" ideas.
--
Jeff Barnett

On Fri, 15 Mar 2024 16:05:37 -0600, Jeff Barnett wrote:

> Once you have had the programming convenience of using dynamic scope,
> you would miss it terribly in a lexical-only language, or worse, in
> something like the old FORTRAN assembler-level scope. Another argument
> that I have not seen debated but may be significant is that the CL Error
> System -- the programming primitives and error class structures don't
> make a lot of sense in lexical only. The error mechanisms like catch
> have meanings that include phrases such as "while executing this. I'm
> available to handle that".

Lexical binding has always been understood to apply to references to
definitions of identifiers. Exception handlers are dynamically-installed
(lexical-based exception handling doesn’t make any sense), nevertheless
the names of the defined exceptions being handled are still lexically-
bound.

This is how it works in every rationally-designed language.

On 2024-03-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 15 Mar 2024 16:05:37 -0600, Jeff Barnett wrote:
>
>> Once you have had the programming convenience of using dynamic scope,
>> you would miss it terribly in a lexical-only language, or worse, in
>> something like the old FORTRAN assembler-level scope. Another argument
>> that I have not seen debated but may be significant is that the CL Error
>> System -- the programming primitives and error class structures don't
>> make a lot of sense in lexical only. The error mechanisms like catch
>> have meanings that include phrases such as "while executing this. I'm
>> available to handle that".
>
> Lexical binding has always been understood to apply to references to
> definitions of identifiers. Exception handlers are dynamically-installed
> (lexical-based exception handling doesn’t make any sense), nevertheless
> the names of the defined exceptions being handled are still lexically-
> bound.
>
> This is how it works in every rationally-designed language.

Names of exceptions (conditions) are not lexically bound in Common Lisp.

They are pervasive, similarly to class names.

Lexically scoped exception handling does make sense, during those
sections of the handling when a lexical scope isn't being abandoned.

If the termination point of an exception is in lexical scope of the
origin, then the case can be made for handling the entire episode
lexically, including the unwinding.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Paul Rubin <no.email@nospam.invalid> writes:

> Is it really true that Common Lisp had both lexical and dynamic scope
> in order to support older code that was written relying on dynamic
> scope and was too hard to convert?

No. I'd say Common Lisp has both lexical and dynamic scope because both
are very useful. For instance, the Guice dependency injection framework
for Java implements @RequestScoped settings, which are dynamically
scoped and thread local. Guice wouldn't need that feature if Java
natively supported dynamically-scoped variables.

On Fri, 15 Mar 2024 20:23:51 -0400, Robert Brown wrote:

> For instance, the Guice dependency injection framework
> for Java implements @RequestScoped settings, which are dynamically
> scoped and thread local.

Can’t find any mention of “dynamic” scoping in the docs
<https://github.com/google/guice/wiki/Scopes>. “@RequestScoped” just
seems to mean what it says: the scope is per-request.

> Guice wouldn't need that feature if Java
> natively supported dynamically-scoped variables.

It seems to me the effect can be achieved more simply by allowing
access to instance methods as first-class objects, as you can do in
Python, e.g.

request_inst = Request(...)
# class instantiation
request_meth = request_inst.meth
# method access

But as usual, Java insists on doing things in a complicated way...

On 2024-03-15, Paul Rubin <no.email@nospam.invalid> wrote:
> Does anyone know when lexical scope started appearing in Lisp? Not
> counting Scheme, did it exist in predecessors of Common Lisp? Was it
> used much? Is it really true that Common Lisp had both lexical and
> dynamic scope in order to support older code that was written relying on
> dynamic scope and was too hard to convert?

Global variables are dynamically scoped in Common Lisp; the standard
language doesn't provide for global variables that are not dynamically
scoped: "dynamic variable", "global variable" and "top-level variable"
refer to the same thing. Common Lisp's lexical scope design therefore
isn't "total" in a sense; it doesn't provide top-level variables.

New Common Lisp code continues to make use of dynamic scope.

Important predefined variables such as the standard streams (e.g.
*standard-output*) are dynamic variables. By locally binding
*standard-output* we can redirect standard output to a different
stream.

In multithreaded Common Lisp implementations, dynamically scoped
variables provide thread-local storage (as an extension to the
language). If each thread can have its own independent binding of a
dynamic variable, it means that the symbol serves as a key
to a thread-specific storage location.

There are good reasons to use dynamic variables in newly written Lisp
code.

For instance, a context handle (e.g. database handle) that rarely
changes and that is passed around in numerous API calls can be a special
variable, and then it doesn't have to be repated in all those calls.
Yet if it has to take on different values, there is a clean way to do
that.

The aforementioned standard streams are such context handles. For
instance when we call (write-strin "abc"), the default destination is
*standard-output*; it need not be mentioned, if desired. The function
will use the current value of the dynamic variable *standard-output*.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 3/15/2024 4:26 PM, Lawrence D'Oliveiro wrote:
> On Fri, 15 Mar 2024 16:05:37 -0600, Jeff Barnett wrote:
>
>> Once you have had the programming convenience of using dynamic scope,
>> you would miss it terribly in a lexical-only language, or worse, in
>> something like the old FORTRAN assembler-level scope. Another argument
>> that I have not seen debated but may be significant is that the CL Error
>> System -- the programming primitives and error class structures don't
>> make a lot of sense in lexical only. The error mechanisms like catch
>> have meanings that include phrases such as "while executing this. I'm
>> available to handle that".
>
> Lexical binding has always been understood to apply to references to
> definitions of identifiers. Exception handlers are dynamically-installed
> (lexical-based exception handling doesn’t make any sense), nevertheless
> the names of the defined exceptions being handled are still lexically-
> bound.
>
> This is how it works in every rationally-designed language.
First off, I believe that many if not most exception-related primitives
expand in terms of dynamic variables. And second, it would be amusing to
unwind to an environment that is lexically alive but execution dead-
think about restarting the contexts that were abandoned.
--
Jeff Barnett

On Sat, 16 Mar 2024 00:46:21 -0600, Jeff Barnett wrote:

> First off, I believe that many if not most exception-related primitives
> expand in terms of dynamic variables.

Consider the following Python example:

class MyException1(Exception) :
pass
#end MyException1

class MyException2(Exception) :
pass
#end MyException2

def func1() :
raise MyException1
#end func1

def func2() :
raise MyException2
#end func2

def func3() :
class MyException1(Exception) :
pass
#end MyException1

try :
func1()
except MyException1 :
# will never get here
print("caught MyException1 in func3")
#end try
#end func3

def func4() :
try :
func2()
except MyException2 :
print("caught MyException2 in func4")
#end try
#end func4

for f in (func1, func2, func3, func4) :
try :
print("* call %s" % f.__name__)
f()
except MyException1 :
print("caught MyException1 at top level")
except MyException2 :
print("caught MyException2 at top level")
#end try
#end for

Here is the output it produces:

* call func1
caught MyException1 at top level
* call func2
caught MyException2 at top level
* call func3
caught MyException1 at top level
* call func4
caught MyException2 in func4

func4 shows how the search for a handler is based on dynamic execution
nesting. func3 shows how exception matching is based on lexical
scoping.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Fri, 15 Mar 2024 20:23:51 -0400, Robert Brown wrote:
>
>> For instance, the Guice dependency injection framework
>> for Java implements @RequestScoped settings, which are dynamically
>> scoped and thread local.
>
> Can’t find any mention of “dynamic” scoping in the docs
> <https://github.com/google/guice/wiki/Scopes>. “@RequestScoped” just
> seems to mean what it says: the scope is per-request.

The use of thread local state to store request scoped Guice bindings is
discussed in this thread:

https://groups.google.com/g/google-guice/c/gDonVGO1wjY/m/_SSi4CcQAJYJ

On 2024-03-16, Jeff Barnett <jbb@notatt.com> wrote:
> On 3/15/2024 4:26 PM, Lawrence D'Oliveiro wrote:
>> On Fri, 15 Mar 2024 16:05:37 -0600, Jeff Barnett wrote:
>>
>>> Once you have had the programming convenience of using dynamic scope,
>>> you would miss it terribly in a lexical-only language, or worse, in
>>> something like the old FORTRAN assembler-level scope. Another argument
>>> that I have not seen debated but may be significant is that the CL Error
>>> System -- the programming primitives and error class structures don't
>>> make a lot of sense in lexical only. The error mechanisms like catch
>>> have meanings that include phrases such as "while executing this. I'm
>>> available to handle that".
>>
>> Lexical binding has always been understood to apply to references to
>> definitions of identifiers. Exception handlers are dynamically-installed
>> (lexical-based exception handling doesn’t make any sense), nevertheless
>> the names of the defined exceptions being handled are still lexically-
>> bound.
>>
>> This is how it works in every rationally-designed language.
>
> First off, I believe that many if not most exception-related primitives
> expand in terms of dynamic variables. And second, it would be amusing to
> unwind to an environment that is lexically alive but execution dead-
> think about restarting the contexts that were abandoned.

That might happen when you call a closure that was saved in such
an environment which was then dynamically abandoned.

When resuming a continuation captured in such an environment, though,
the dynamics have to appear intact.

(defun grandkid ()
(unwind-protect
(yield-from parent 'in-grandkid)
(put-line "returning from grandkid")))
(defun kid ()
(unwind-protect
(progn
(yield-from parent 'in-kid)
(grandkid))
(put-line "returning from kid")))

(defun parent ()
(unwind-protect
(progn
(yield-from parent 'in-parent)
(kid))
(put-line "returning from parent")))

(let ((fn (obtain (parent))))
(prinl 'a)
(prinl (call fn))
(prinl 'b)
(prinl (call fn))
(prinl 'c)
(prinl (call fn))
(prinl 'd)
(prinl (call fn))
(prinl 'e))

Run:

$ txr cont.tl
a
in-parent
b
in-kid
c
in-grandkid
d
returning from grandkid
returning from kid
returning from parent
nil
e

When (call fn) resumes the delimited continuation, the stack linkage is all
there: the unwind protect exit points, and all else. Dynamic variable bindings
also, though that is not apparent in this example. If you resume a continuation
into somwhere where *stdout* is redirected to a string, it's redirected to a
string via dynamic binding, that redirection is correctly observed.

To make this work, I didn't even give a second thought to the horrendously
impractical "dynamic-wind", which is dead on arrival from a feasability
point of view.

How it works is that the yield-from invocations perform an "absconding"
dynamic control transfer. An absconding control transfer is like a regular
dynamic control transfer, except it performs no unwinding.

1> (block foo (unwind-protect (sys:abscond-from foo 42) (prinl 'unwind)))
42
2> (block foo (unwind-protect (return-from foo 42) (prinl 'notprinted)))
notprinted
42

Abscond is a sharp knife, so it's kept in the system package, though
it is a documented feature.

If we resume the came continuation, we can repeatedly invoke the
same unwinding:

1> (block nil
(unwind-protect
(sys:capture-cont nil 'identity) ;; capture up to nil block
(prinl 'unwind)))
unwind
#<intrinsic fun: 1 param>
2> [*1 42] ;; call continuation
unwind
42
3> [*1 42]
unwind
42
4> [*1 42]
unwind
42
5> [*1 42]
unwind
42

(The yield stuff avoids this by updating the yield contexts to new
continuations which resume from the previously yielded point,
like a cooperative thread.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sat, 16 Mar 2024 11:32:46 -0400, Robert Brown wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 15 Mar 2024 20:23:51 -0400, Robert Brown wrote:
>>
>>> For instance, the Guice dependency injection framework for Java
>>> implements @RequestScoped settings, which are dynamically scoped and
>>> thread local.
>>
>> Can’t find any mention of “dynamic” scoping in the docs
>> <https://github.com/google/guice/wiki/Scopes>. “@RequestScoped” just
>> seems to mean what it says: the scope is per-request.
>
> The use of thread local state to store request scoped Guice bindings is
> discussed in this thread:
>
> https://groups.google.com/g/google-guice/c/gDonVGO1wjY/m/_SSi4CcQAJYJ

You mean the commenter who says “I'm not saying this is
often (or even ever) a good thing to do; I'm just illustrating the
technique”?

On 3/16/2024 1:27 AM, Lawrence D'Oliveiro wrote:
> On Sat, 16 Mar 2024 00:46:21 -0600, Jeff Barnett wrote:
>
>> First off, I believe that many if not most exception-related primitives
>> expand in terms of dynamic variables.
>
> Consider the following Python example:
>
> class MyException1(Exception) :
> pass
> #end MyException1
>
> class MyException2(Exception) :
> pass
> #end MyException2
>
> def func1() :
> raise MyException1
> #end func1
>
> def func2() :
> raise MyException2
> #end func2
>
> def func3() :
> class MyException1(Exception) :
> pass
> #end MyException1
>
> try :
> func1()
> except MyException1 :
> # will never get here
> print("caught MyException1 in func3")
> #end try
> #end func3
>
> def func4() :
> try :
> func2()
> except MyException2 :
> print("caught MyException2 in func4")
> #end try
> #end func4
>
> for f in (func1, func2, func3, func4) :
> try :
> print("* call %s" % f.__name__)
> f()
> except MyException1 :
> print("caught MyException1 at top level")
> except MyException2 :
> print("caught MyException2 at top level")
> #end try
> #end for
>
> Here is the output it produces:
>
> * call func1
> caught MyException1 at top level
> * call func2
> caught MyException2 at top level
> * call func3
> caught MyException1 at top level
> * call func4
> caught MyException2 in func4
>
> func4 shows how the search for a handler is based on dynamic execution
> nesting. func3 shows how exception matching is based on lexical
> scoping.

Unfortunately, I don't speak Python. However if your point is that you
can build "simulations" of one sort of scoping out of primitives for
another sort, I agree.

In fact Doug Pintar and I invented and used a language called CRISP
(https://www.softwarepreservation.org/projects/LISP/crisp_ibm370_sdc) in
the 1070s. It was used to implement some interesting speech
understanding systems as part of the DARPA SUR Program. CRISP Allowed
local and dynamic bindings and stack segments including bindings,
catches, and return points where represented. There where primitives
that allowed these stack segments to be elements of three types of
trees: binding trees where dynamic bindings not located in one segment
where sought in the parent segment; resume trees where segment
executions did a return that was not handled in the current segment were
reflected to the parent segment; and handler trees where a throw not
handled by the executing segment was continued into the parent segment.
The "highest" node in all trees was the global context. The parent-child
relation in all trees could be rearranged under program control. Out of
the related primitives, e.g., eval-in(exp, segment) you could construct
pretty much whatever binding, control. and error handling structure that
you needed. The reason for this baroque approach is that when we started
constructing speech systems we had absolutely no idea what program
organization structures would be convenient.

The above was inspired by some papers using the rubric "spaghetti
stacks". Don't remember the authors but Danny Bobrow might have been
implicated.
--
Jeff Barnett

On Sat, 16 Mar 2024 23:13:20 -0600, Jeff Barnett wrote:

> However if your point is that you can build "simulations" of one sort of
> scoping out of primitives for another sort ...

No, my point was that there seems to be no need for dynamic scoping, if
the only excuse anyone can come up for needing it comes out of exception
handling.

Paul Rubin <no.email@nospam.invalid> wrote:

> Does anyone know when lexical scope started appearing in Lisp? Not
> counting Scheme, did it exist in predecessors of Common Lisp? Was it
> used much? Is it really true that Common Lisp had both lexical and
> dynamic scope in order to support older code that was written relying
> on dynamic scope and was too hard to convert?

That question should be answered by someone from the standardizing
committee, but anyway I think that there's two questions here.

Dynamic scope is necessary for some things (e.g. mutable global
variables, the condition system, thread-local storage, etc.), and then
there is the general user-level facility for declaring special
variables. So it might very well be that the original motivations for
those are different...

--
Resistance is futile. You will be jazzimilated.

Jazz site: http://www.didierverna.com
Other sites: http://www.didierverna.info

On Sun, 17 Mar 2024 10:41:01 +0100, Didier Verna wrote:

> Dynamic scope is necessary for some things (e.g. mutable global
> variables, the condition system, thread-local storage, etc.) ...

Can’t see the reasoning behind any of those three examples. Thread-local
storage is the same as global variables, and global scope is just the
outermost lexical scope. As for the condition system, see my example
showing how a lexically-scoped language like Python can handle that.

On 3/16/2024 11:37 PM, Lawrence D'Oliveiro wrote:
> On Sat, 16 Mar 2024 23:13:20 -0600, Jeff Barnett wrote:
>
>> However if your point is that you can build "simulations" of one sort of
>> scoping out of primitives for another sort ...
>
> No, my point was that there seems to be no need for dynamic scoping, if
> the only excuse anyone can come up for needing it comes out of exception
> handling.

That wasn't the only thing mentioned. In fact it was said to be quite
useful and desired without enumeration of reasons. You of course chopped
many original messages above to remove some of those "short glowing
reviews" then got on your hobby horse and started to ride.

Just think of the following when specifying a variable's intent: is it
supposed to influence an evaluation or is it supposed to influence an
evaluation when it's in a particular lexical scope? Does that help you any?

The example of error handling is that it's generally supposed to control
an evaluation. If error handling was lexically based then you would need
to decide what to do when evaluate(x) occurs and the handling of certain
conditions are specified in a scope not available when x was defined.
There are choices and lots of them. When dynamic and lexical flow trees
are different, you must decide by language rules or provide primitives
to users that allows them to sort out intent. If you don't have any
"special" variables around, you'll find that rather difficult.

Lexical-only is nice and neat for many applications and philosophies of
programming. But not all by a long shot. If that approach satisfies you,
I'd suggest ALGOL or even SIMULA. Alan Perlis even saw uses for dynamic
visibility (private communications) and discussed the thought that OWN
variables did not satisfy those uses. There was an ambiguity in the
second ALGOL spec on the requirements for OWN variables: if the spec was
read one way, a particular function computed a Legendre polynomial; read
the other way, it computed a Bessel function! (It's been a long time and
I don't remember the exact pair of function families that were
confounded.) In any event, the issue had to do for the rules about when
an OWN needed to be bound and it was possible to have multiple bindings
simultaneously! I believe this latter fact was tied up with trying to
allow OWNS to act more like SPECIAL.
--
Jeff Barnett

On Sun, 17 Mar 2024 16:42:34 -0600, Jeff Barnett wrote:

> Just think of the following when specifying a variable's intent: is it
> supposed to influence an evaluation or is it supposed to influence an
> evaluation when it's in a particular lexical scope? Does that help you
> any?

Seems you phrased that wrong: it should be “is it supposed to influence an
evaluation or is it supposed to influence an evaluation when it’s in a
particular *dynamic* scope”? Because a variable in a lexical scope is
always in that lexical scope, no “when” about it.

> The example of error handling is that it's generally supposed to control
> an evaluation. If error handling was lexically based ...

I didn’t say error handling was lexically based, I said the matching of
exceptions was lexically based. I thought my example made that distinction
clear.

In article <ut7rkt$3p750$1@dont-email.me>,
Jeff Barnett <jbb@notatt.com> wrote:
>second ALGOL spec on the requirements for OWN variables: if the spec was

You can't refer to ALGOL like this. It is either ALGOL60 or ALGOL68.
These are totally different languages.
ALGOL60 is an early experiment. ALGOL68 is practically Google's go.

>--
>Jeff Barnett
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

On Mon, 18 Mar 2024 14:47:29 +0100, albert wrote:

> ALGOL60 is an early experiment.

Actually, the “early experiment” was IAL, a.k.a. ALGOL58.

And then there was “ALGOL-W”, a.k.a. “Wirth-Hoare ALGOL”, which was the
precursor to Pascal.

On Mon, 18 Mar 2024 14:47:29 +0100, albert@spenarnc.xs4all.nl wrote:

>In article <ut7rkt$3p750$1@dont-email.me>,
>Jeff Barnett <jbb@notatt.com> wrote:
>>second ALGOL spec on the requirements for OWN variables: if the spec was
>
>You can't refer to ALGOL like this. It is either ALGOL60 or ALGOL68.
>These are totally different languages.
>ALGOL60 is an early experiment. ALGOL68 is practically Google's go.

FWIW: ALGOL68 was described by two different reports using completely
different grammar notation.

[1] Report on the Algorithmic Language ALGOL 68
[2] Revised Report on the Algorithmic Language ALGOL 68

The original report used a "Van Wijngaarden" (vW) grammar. vW grammars
are 2-level, consisting of a conventional attribute grammar, augmented
by a "meta" grammar which describes the possible values of attributes
in the 1st grammar. In theory, a vW grammar can do wonderful things
such as turn type errors into syntax errors.

Unfortunately, vW grammars are Turing Complete - programming languages
in themselves. The grammar in the ALGOL 68 report widely was
considered to be too difficult for many compiler implementors to
understand.

Thus the report was rewritten using an adhoc notation called "NEST"
[which AFAICT was never used again]. NEST also was 2-level and able to
describe attribute values, but more verbose than vW, and deliberately
made not Turing Complete.

However, the grammars in the two reports are so different that they
are difficult to compare, and there was/is some debate as to whether
they truly describe the same language. In any event, almost all
AlGOL68 compilers were said to have been developed using the revised
report.

[1]
https://pdfroom.com/books/report-on-the-algorithmic-language-algol-68/Jr2ELK1agyv
[2]
https://www.softwarepreservation.org/projects/ALGOL/report/Algol68_revised_report-AB-600dpi.pdf

On 3/17/2024 5:05 PM, Lawrence D'Oliveiro wrote:
> On Sun, 17 Mar 2024 16:42:34 -0600, Jeff Barnett wrote:
>
>> Just think of the following when specifying a variable's intent: is it
>> supposed to influence an evaluation or is it supposed to influence an
>> evaluation when it's in a particular lexical scope? Does that help you
>> any?
>
> Seems you phrased that wrong: it should be “is it supposed to influence an
> evaluation or is it supposed to influence an evaluation when it’s in a
> particular *dynamic* scope”? Because a variable in a lexical scope is
> always in that lexical scope, no “when” about it.
Given the sort of languages we are talking about (e.g., not CRISP
described above) you really can't escape from one dynamic scope to
another. You need coroutines that have no start/restart commitments to
one another.
>> The example of error handling is that it's generally supposed to control
>> an evaluation. If error handling was lexically based ...
>
> I didn’t say error handling was lexically based, I said the matching of
> exceptions was lexically based. I thought my example made that distinction
> clear.
Maybe it did but not to me.
--
Jeff Barnett

On Mon, 18 Mar 2024 23:02:23 -0600, Jeff Barnett wrote:

> ... you really can't escape from one dynamic scope to
> another.

Au contraire, with dynamic scoping, such “escaping” happens all the time.

Here’s an example from a language, namely Perl, which does allow for
dynamic scoping (in fact, early on it had no lexical scoping):

$a = 1;

sub f1()
{
$a = $a + 1;
} # f1

sub f2()
{
local $a = 3;
print "inner ", $a, "\n";
f1();
print "inner ", $a, "\n";
} # f2

f1();
print "outer ", $a, "\n";
f2();
print "outer ", $a, "\n";
f1();
print "outer ", $a, "\n";

The output is

outer 2
inner 3
inner 4
outer 2
outer 3

>> I didn’t say error handling was lexically based, I said the matching of
>> exceptions was lexically based. I thought my example made that
>> distinction clear.
>
> Maybe it did but not to me.

Look back again, and see how the outer exception is not the same as the
one with the same name local to the function, yet the catch clauses search
for the exceptions according to dynamic execution nesting.

Want me to go over it step-by-step?

Paul Rubin <no.email@nospam.invalid> writes:

> Does anyone know when lexical scope started appearing in Lisp?

You should find some information in

Steele, Guy L., and Richard P. Gabriel. "The evolution of Lisp."
History of programming languages---II. 1996. 233-330.
https://dl.acm.org/doi/pdf/10.1145/234286.1057818

For instance:

--8<---------------cut here---------------start------------->8---
When the IBM 370 came out, Lisp370 implementation began. [...]

Lisp370 supported both special binding and lexical binding, as well as
closures over both lexical and special variables, using a technique
similar to spaghetti stacks. (Page 31.)
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
Scheme was one of the first languages to have taken seriously the
implications of lexical scoping (as opposed to local scoping, which
had been in use in Lisp compilers for almost a decade) and first-class
functions. (Page 23.)
--8<---------------cut here---------------end--------------->8---