Yielding loop-clauses [Was: Re: Interview with Marcel van der Veer.]

[chris hermansen]

Good morning everyone,

On Sat, Oct 4, 2025 at 1:43 AM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> Hi Chris.
>
> > As Marcel mentions, it's tempting to come up with a list of improvements
> to
> > Algol 68.
> >
> > I have often wondered why the decision was taken to not have the FOR ...
> DO
> > ... OD not return the last value of the loop counter.  Perhaps it is
> > related to the use of DO ... OD without a FOR part?
>
> That is an interesting observation.
>
> The Report says that a counter actually exists even in loop clauses
> without Frobyts.  It is just not accessible, and it certainly doesn't
> need to be implemented.  See https://jemarch.net/a68-jargon/Frobyt.html.
>
> Now, in a loop clause without Frobyts the do-part my be elaborated an
> arbitrary number of times, including infinite.  The iterator of the loop
> clause is defined to be of mode "int", which is signed.
>

So assuming there is an environment enquiry last_loop_index_value, in the
case of nested loops e.g.

WHILE a /= something DO
    { some processing, possibly changing the value of a }
    WHILE b /= something_else DO
        { more processing, including changing value of b and possibly a }
   OD;
   { look at last_loop_index_value for inner loop and possibly doing
something with the value returned }
   { more processing, possibly changing the value of a }
OD;
{ look at last_loop_index_value for outer loop and possibly doing something
with the value returned }

That's the kind of thing being discussed, correct?

Would this be accessible only in the scope that contains the DO ... OD?
What about a loop terminated from within by a GOTO?  What about when the
label is outside the scope containing the DO ... OD?

What about collateral or parallel-collateral evaluation of loops?


We still need to discuss and decide what to do with signed overflow in
> GNU Algol 68.  I am for avoiding UB, like the Rust people did, because
> it is easy and I don't see any drawback other than compiler
> optimizations: optional run-time checks and two's complement wrapping.
> In Algol 68 we have many other run-time checks that are optional, so
> that
>
> If we define signed overflow then the value yielded by a Frobyts-free
> loop becomes also defined.  A downside is that the optimization of not
> implementing the iterator in these loops can only be done when the
> yielded value is voided, but this is Algol 68, so we can detect these
> cases ^^
>

It would be nice to be able to turn off overflow checking; for example,
when calculating a hash value, it's nice (and more efficient) just to let
overflows happen, rather than checking on each iteration whether the
computation will result in an overflow.  Maybe with a pragmat?

But the concept of FOR i FROM 1 BY 17 TO max_int DO ... OD never
terminating and never causing an exception, yep that's an interesting
consequence of signed integers wrapping around...

Maybe this is a good point to mention again that I find it kind of odd that
Algol 68 seems to think all INTs live between - max_int and max_int.

>
> > Another possibility is that it return the value of the last expression
> > evaluated on the last pass through the loop, in which case the loop
> counter
> > return could be achieved by
> >
> > FOR i FROM 1 TO 100 DO
> >     ...
> >     i
> > OD
>
> This is a nice idea, but it would require changing Algol 68:
>
>   3.5 Loop clauses
>
>   3.5.1 Syntax
>
>   h) NEST3 STYLE do part{3,f} :
>        STYLE do{94g,-} token,
>          strong void NEST3 serial clause defining LAYER4{32a},
>          STYLE od{94g,-} token.
>
> Note how the serial clause is in a void strong context.  This means the
> value yielded is voided, so you lose it.
>

I guess that change is in fact what I was proposing!


>
> > Related, I have found myself defining procedures that iterate and take a
> > procedure as the last argument, which is called on each iteration. I
> > generally like this modality, for example reading lines from a text file,
> > where the each_line() procedure manages the file opening, EOF detection,
> > closing etc.
> >
> > I haven't got around to defining similar procedures for map(), reduce()
> and
> > similar functionality and I expect that strong typing without mode
> > templates or similar will limit the generality of such procedures (unless
> > we can surface something like INTYPE / OUTTYPE).
> >
> > I guess I feel that Algol 68 is so close to being able to usefully
> support
> > a functional approach that it would be neat to figure out the minimal
> > amount needed to push it over the line.
>
> We will be thinking about and implementing modals soon enough :)
>
> But upstreaming, separated compilation and modules come first.
> So much to do, arf.
>

For what it's worth, I continue to be excited by this Algol 68 renaissance
that you and Marcel are driving.  Thanks very much for that!


-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20251004/0b146cab/attachment.htm>