From Newsgroup: comp.lang.misc

This was something new to me; I learned that in

INT n = 8;
[n] REF [] INT tri;
FOR i TO n DO
tri[i] := LOC [i] INT # LOC is okay #
OD;

between the DO and the OD there's no Local Range!
With the consequence that the LOC element will be
accessible outside the FOR loop!

And that the Local Range "gets into existence" by
some (even unrelated) declaration, so that in

INT n = 8;
[n] REF [] INT tri;
FOR i TO n DO
INT j := n; # establishes local range #
tri[i] := LOC [i] INT # => error #
OD;

the same (previously valid) code becomes an error
only by existence of the "spurious" declaration.

I find that quite irritating; I'd have expected
that even a closed clause without any declaration
would constitute an (albeit "empty") Local Range.

What's the rationale behind that design decision?

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 20/12/2025 12:28, Janis Papanagnou wrote:

This was something new to me; I learned that in
    INT n = 8;
    [n] REF [] INT tri;
    FOR i TO n DO
        tri[i] := LOC [i] INT     # LOC is okay #
    OD;
between the DO and the OD there's no Local Range!

My reading of RR3.5 interprets that as incorrect, so I think
this is an A68G-ism. I can't offhand see a stated difference between
A68 and A68G in this area, but I just have an impression that A68G
tries to minimise the number of nested ranges.

With the consequence that the LOC element will be
accessible outside the FOR loop!

Lucky you! Saves some HEAPs ....

And that the Local Range "gets into existence" by
some (even unrelated) declaration, so that [...]
the same (previously valid) code becomes an error
only by existence of the "spurious" declaration.

Yes.

I find that quite irritating; I'd have expected
that even a closed clause without any declaration
would constitute an (albeit "empty") Local Range.
What's the rationale behind that design decision?

I think you've almost said it. Entering and exiting a range could
well cost time and code, particularly significant in a loop. So eliding
ranges where possible presumably speeds up your program, at the expense of
your irritation. Marcel may think that a bargain?
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Valentine
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2025-12-20 15:01, Andy Walker wrote:

On 20/12/2025 12:28, Janis Papanagnou wrote:

This was something new to me; I learned that in
     INT n = 8;
     [n] REF [] INT tri;
     FOR i TO n DO
         tri[i] := LOC [i] INT     # LOC is okay #
     OD;
between the DO and the OD there's no Local Range!

    My reading of RR3.5 interprets that as incorrect, so I think
this is an A68G-ism.  I can't offhand see a stated difference between
A68 and A68G in this area, but I just have an impression that A68G
tries to minimise the number of nested ranges.

Actually, it wouldn't have appeared to me to use such a construct in
that context; I'd certainly used (without thinking) just a HEAP. And
even now that I know this Algol 68 particularity I'd not make use of
it (I think for obvious reasons).

Re "A68G"; actually (AFAICT) that's not a Genie issue. I found that
property explicitly described and with a similar example in
Lindsey, van der Meulen: "Informal Introduction to ALGOL 68" [*]
(If I understand correctly that's an informal amendment to the RR?)

Janis

[*] https://inria.hal.science/hal-03027689/file/Lindsey_van_der_Meulen-IItA68-Revised.pdf

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sat, 20 Dec 2025 14:01:27 +0000, Andy Walker wrote:

My reading of RR3.5 interprets that as incorrect, so I think this is
an A68G-ism.

Particularly since the loop index is supposed to be a constant, and by
normal Algol 68 rules you can’t redeclare a constant (as needs to
happen each time round the loop) without entering a new scope.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2025-12-21 02:59, Lawrence D’Oliveiro wrote:

On Sat, 20 Dec 2025 14:01:27 +0000, Andy Walker wrote:

My reading of RR3.5 interprets that as incorrect, so I think this is
an A68G-ism.

Particularly since the loop index is supposed to be a constant, and by
normal Algol 68 rules you can’t redeclare a constant (as needs to
happen each time round the loop) without entering a new scope.

This backing still ignores what Lindsey/van der Meulen wrote in
1977. Their document contains clear statements about the effect
being part of Algol 68. (You know the authors were both engaged
in Algol 68.)

Also the explanation doesn't serve well. For one, the implicitly
declared loop constant is a special case in Algol 68. And second,
the loop can semantically (also) be explained as the iterative
form of the corresponding recursive functional counterpart where
naturally the identity relations are just images of the "frozen"
formal function arguments. The latter semantics was actually the
explanation that F.L.Bauer and R.Bayer gave us decades back.

Thinking about it; the functional interpretation might even serve
to explain the actual rationale that I was initially asking for.
Hmm..

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 20/12/2025 16:39, Janis Papanagnou wrote:
[re "LOC" inside loops:]

Re "A68G"; actually (AFAICT) that's not a Genie issue. I found that
property explicitly described and with a similar example in
Lindsey, van der Meulen: "Informal Introduction to ALGOL 68" [*]

Hmm. You seem to be correct. "FOR i ..." seems to be a local definition of "i", but technically not a declaration, so that a few
weasel words later, you get the effect you describe. So in deeply nested
loops you can have arbitrarily many copies of values with the same
identifier. This is pretty yucky, IMO, and also breaks the equivalence
of loops with "the same" code written out using jumps and explicit tests
[as described in the RR].

(If I understand correctly that's an informal amendment to the RR?)

No, it's supposed to be an informal description of A68, readable
by people who don't understand two-level grammars. Technically, there
can be no amendments to the RR. The Cttee hath spoken! The most you can
claim is that there are typos, so that the editor of Algol Bulleting can
report imperfections in the copying process that produced paper copies of
the RR. I fear that's the sort of thing that gave A68 a bad name. There
were enough errors [I found and reported half a dozen] that an updated RR
would not have been a bad thing,
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Hummel
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2025-12-22 18:35, Andy Walker wrote:

On 20/12/2025 16:39, Janis Papanagnou wrote:
[re "LOC" inside loops:]

Re "A68G"; actually (AFAICT) that's not a Genie issue. I found that
property explicitly described and with a similar example in
Lindsey, van der Meulen: "Informal Introduction to ALGOL 68" [*]

    Hmm.  You seem to be correct.  "FOR i ..." seems to be a local definition of "i", but technically not a declaration, so that a few
weasel words later, you get the effect you describe.  So in deeply nested loops you can have arbitrarily many copies of values with the same identifier.  This is pretty yucky, IMO, and also breaks the equivalence
of loops with "the same" code written out using jumps and explicit tests
[as described in the RR].

I also don't like it. Moreover, I think it muddies the clean language
design. - On the other hand, if I hadn't read that paper I probably
wouldn't ever have noticed it in practice.

(If I understand correctly that's an informal amendment to the RR?)

    No, it's supposed to be an informal description of A68, readable
by people who don't understand two-level grammars.  [...]

I thought to have read somewhere that the committee members would have "accepted" it [informally] as clarifying document. (But okay, I may be
just mistaken with my reading or interpretation of some statements.)

BTW, I think the explanation level of that paper is quite good. (I'm
generally not an advocate of using formal standard documents for plain programmers.) This paper fills the gap quite well between a textbook
and all the formal details (and peculiar language) you typically find
in standards.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Mon, 22 Dec 2025 17:35:03 +0000, Andy Walker wrote:

There were enough errors [I found and reported half a dozen] that an
updated RR would not have been a bad thing,

Sort of an ... RRR ... ?
--- Synchronet 3.21a-Linux NewsLink 1.2