From Newsgroup: comp.lang.misc

Is there a way in Algol 68 that I can create an array indexed [0..1] of procedures to be initialized by an _identity_ declaration as 'p' below?

PROC g = BOOL : ... ;
PROC h = BOOL : ... ;

[] PROC BOOL p =
CASE n IN
( h, g ),
( g, h )
ESAC;

Like this code but array 'p' with indices 0..1 (instead of 1..2).

Declaring 'p' with [0:1] isn't possible it seems for the identity case
where a formal [] declarer seems necessary. While an _assignment_ like

[0:1] PROC BOOL p := ... ;

is obviously possible.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 01/11/2025 15:00, Janis Papanagnou wrote:

Is there a way in Algol 68 that I can create an array indexed [0..1] of procedures to be initialized by an _identity_ declaration as 'p' below?
PROC g = BOOL : ... ;
PROC h = BOOL : ... ;
[] PROC BOOL p =
CASE n IN
( h, g ),
( g, h )
ESAC;
Like this code but array 'p' with indices 0..1 (instead of 1..2).

The problem is that "(h,g)" is an array indexed starting at 1.
So you need to re-base the array by using "[@0]". The obvious place to
put that is immediately after the "ESAC", but A68G complains on the
perhaps spurious ground that the "[@0]"can only be applied to a row or
similar. I don't know whether this is also a true A68 limitation or a
minor A68G bug/divergence. The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".

Declaring 'p' with [0:1] isn't possible it seems for the identity case
where a formal [] declarer seems necessary.

True. In "[] PROC BOOL p = whatever", "p" takes its bounds from
those of "whatever", so it's "whatever" rather than "p" that has to have
the bounds you want.

While an _assignment_ like
[0:1] PROC BOOL p := ... ;
is obviously possible.

It's possible, but you will still have problems unless "..." has
bounds "0:1". In cases similar to your code above, it might still be best
to create an object specifically of the correct type/mode, so starting at
1 by default and then re-basing that.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Ascher
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 01.11.2025 21:54, Andy Walker wrote:

On 01/11/2025 15:00, Janis Papanagnou wrote:

Is there a way in Algol 68 that I can create an array indexed [0..1] of
procedures to be initialized by an _identity_ declaration as 'p' below?
PROC g = BOOL : ... ;
PROC h = BOOL : ... ;
[] PROC BOOL p =
CASE n IN
( h, g ),
( g, h )
ESAC;
Like this code but array 'p' with indices 0..1 (instead of 1..2).

The problem is that "(h,g)" is an array indexed starting at 1.
So you need to re-base the array by using "[@0]".

Yeah. I had tried a couple variants with '[AT 0]', but to no avail.

The obvious place to put that is immediately after the "ESAC",

It didn't occur to me to extract these to an outer level here. In my
tries I've had spread the 'AT's at the array elements directly.

but A68G complains on the
perhaps spurious ground that the "[@0]"can only be applied to a row or similar.

These Genie's errors was that made me finally give up my tries.

I don't know whether this is also a true A68 limitation or a
minor A68G bug/divergence.

Maybe I'll also ask what Marcel thinks; specifically concerning Genie,
or generally concerning the standard. (Maybe it's an oversight; can't
tell.)

The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".

I had intended to avoid "spurious" declarations, but to keep the later
code's logic clearer it might be worth to follow that path.

Declaring 'p' with [0:1] isn't possible it seems for the identity case
where a formal [] declarer seems necessary.

True. In "[] PROC BOOL p = whatever", "p" takes its bounds from
those of "whatever", so it's "whatever" rather than "p" that has to have
the bounds you want.

While an _assignment_ like
[0:1] PROC BOOL p := ... ;
is obviously possible.

It's possible, but you will still have problems unless "..." has
bounds "0:1". In cases similar to your code above, it might still be best
to create an object specifically of the correct type/mode, so starting at
1 by default and then re-basing that.

Thanks.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 02.11.2025 07:33, Janis Papanagnou wrote:

On 01.11.2025 21:54, Andy Walker wrote:

[...]

I don't know whether this is also a true A68 limitation or a
minor A68G bug/divergence.

Maybe I'll also ask what Marcel thinks; specifically concerning Genie,
or generally concerning the standard. (Maybe it's an oversight; can't
tell.)

I've sent an email; we'll see.

The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".

This is what I'm now doing. It's clear enough, only little overhead.

[...] In cases similar to your code above, it might still be best

to create an object specifically of the correct type/mode, so starting at
1 by default and then re-basing that.

(Trying a MODE declaration for a [0:1] array didn't solve the issue.
And the '(g, h)' initializer expression I couldn't force to [0:1].)

Meanwhile I'll go with your "p = pp[@0]" suggestion above. Thanks.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 02/11/2025 06:33, Janis Papanagnou wrote:

On 01.11.2025 21:54, I wrote:

The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".

I had intended to avoid "spurious" declarations, but to keep the later
code's logic clearer it might be worth to follow that path.

A slightly different approach would use a cast:

[] PROC BOOL p = [] PROC BOOL CASE ... ESAC [@0];

That avoids the extra declaration, but I'm unconvinced that it's as clear
-- good luck trying to explain how that all works to a class of students!
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Rubinstein
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 02/11/2025 11:10, Andy Walker wrote:

On 02/11/2025 06:33, Janis Papanagnou wrote:

On 01.11.2025 21:54, I wrote:

The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".

I had intended to avoid "spurious" declarations, but to keep the later
code's logic clearer it might be worth to follow that path.

    A slightly different approach would use a cast:

  [] PROC BOOL p = [] PROC BOOL CASE ... ESAC [@0];

That avoids the extra declaration, but I'm unconvinced that it's as clear
-- good luck trying to explain how that all works to a class of students!

Is this a general problem when using a (...) constructor, in that the
natural bounds start from 1?

I couldn't get this to work:

[0:3]INT a := (10, 20, 30);

It prefers empty bounds, but those default to 1:. Using [0:] didn't
work. Trying that [@0] didn't work either, for example:

[0:3]INT a;
a := (10, 20, 30) [@0];

It seems a weak spot in the language.

(In my languages which borrowed the syntax, I use:

[0:]int a := (10, 20, 30) # static typing
a := (0: 10, 20, 30) # dynamic typing

Arrays in static code are often unbounded, but can still have any LWB. A constructor like (10, 20, 30) adapts itself to the requirements; it can initialise a struct for example.)


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 02.11.2025 12:44, bart wrote:

On 02/11/2025 11:10, Andy Walker wrote:

On 02/11/2025 06:33, Janis Papanagnou wrote:

On 01.11.2025 21:54, I wrote:

The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".

I had intended to avoid "spurious" declarations, but to keep the later
code's logic clearer it might be worth to follow that path.

A slightly different approach would use a cast:

[] PROC BOOL p = [] PROC BOOL CASE ... ESAC [@0];

That avoids the extra declaration, but I'm unconvinced that it's as clear
-- good luck trying to explain how that all works to a class of students!

Is this a general problem when using a (...) constructor, in that the
natural bounds start from 1?

I couldn't get this to work:

[0:3]INT a := (10, 20, 30);

Actually, your result is a variant of the problem I described in my
post.

It prefers empty bounds, but those default to 1:. Using [0:] didn't
work. Trying that [@0] didn't work either, for example:

[0:3]INT a;
a := (10, 20, 30) [@0];

It seems a weak spot in the language.

To me - and I understood Andy that way as well - it's not clear whether
it's a restriction in Genie or Algol 68.

Andy presented a workaround; in case of your example something like

[4] INT a := ( 10, 20, 30, 40 );
[0:3] INT b := a [AT 0];


Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2