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.

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?