From Newsgroup: comp.lang.misc

Resuming some recreational Algol 68 programming I'm working on an array-of-array (row-of-row) structure. I started as so often with
a specific function, say,

PROC permute_nums = (REF MAT m) VOID :
FOR y TO 1 UPB m DO
FOR x TO 2 UPB m DO
REF INT where = m [y, x];
where := num [where]
OD
OD;

Since these nested loops are clumsy and are expected to appear in
some more functions I added a generic variant

OP ITERATE = (REF MAT m, PROC (REF INT) VOID f) VOID :
FOR y TO 1 UPB m DO
FOR x TO 2 UPB m DO
REF INT where = m [y, x];
f (where)
OD
OD;

where the specific transformation function is passed as a parameter.

Now I'm not too much concerned about performance but more about the
clarity of the source code. It's certainly an advantage to have the loop-hierarchy only in one place. On the other hand you then either
need a set of additional primitive transformation functions to feed
the operator, or use ad hoc function bodies explicitly in the call of
the generic operator; both variants degrade the overall code clarity
again. - I wonder what people usually prefer.

That said; a related function is printing the data. But here a simple
'f (where)' isn't sufficient; we need newlines printed after the two
'OD' for proper formatting. So a simple 'iterate' as depicted isn't
sufficient anyway.

Comments on these ruminations, thoughts and ideas, are welcome.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 14/04/2026 14:04, Janis Papanagnou wrote:

Resuming some recreational Algol 68 programming I'm working on an array-of-array (row-of-row) structure. I started as so often with
a specific function, say,
    PROC permute_nums = (REF MAT m) VOID :
        FOR y TO 1 UPB m DO
            FOR x TO 2 UPB m DO
                REF INT where = m [y, x];
                where := num [where]
            OD
        OD;
Since these nested loops are clumsy and are expected to appear in
some more functions I added a generic variant

[code snipped -- ANW]

where the specific transformation function is passed as a parameter.
Now I'm not too much concerned about performance but more about the
clarity of the source code. [...]

Personally, I find the non-generic version clearer. ISTM that
you're opening cans of worms with the generic version as well as making
the code harder to understand. You yourself give the example of
printing the array, where you need to add layout code. So you either
have to write two generic versions, or add extra parameters to the one
version. More generally you may want/need to add code between elements
of the array or at the start/end of each row, complicating the generic
version beyond reason and/or leading to the possibility of fence-post
errors. KISS!

Comments on these ruminations, thoughts and ideas, are welcome.

I don't feel that four lines of code to iterate through a two- dimensional array is difficult to write or understand. If it was a 6D
array, you might [IMO] have more reason to avoid repeating the obvious
loops. OTOH, that might give you cause to simplify the data structures
or take a different approach, such as pre-processing the code.

[I once, some years ago, spent a lot of time solving puzzles
involving tree searches (eg, for Slitherlink, Light-Up and Hashi). I
tried to write generic code for the relevant parallel processing, but
in the end it was (much) easier to write the specific code for one
puzzle and copy-and-edit it for the next puzzle. YMMV.]

Andy
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Sinding
--- Synchronet 3.21f-Linux NewsLink 1.2