Groups | Search | Server Info | Login | Register


Groups > comp.lang.misc > #11781

Re: Algol 68 - ruminations on hiding loop hierarchies in an operator

From Andy Walker <anw@cuboid.co.uk>
Newsgroups comp.lang.misc
Subject Re: Algol 68 - ruminations on hiding loop hierarchies in an operator
Date 2026-04-17 15:54 +0100
Organization Not very much
Message-ID <10rthj9$2a1uc$1@dont-email.me> (permalink)
References <10rle06$v392$4@dont-email.me>

Show all headers | View raw


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

Back to comp.lang.misc | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Algol 68 - ruminations on hiding loop hierarchies in an operator Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-14 15:04 +0200
  Re: Algol 68 - ruminations on hiding loop hierarchies in an operator Andy Walker <anw@cuboid.co.uk> - 2026-04-17 15:54 +0100
    Re: Algol 68 - ruminations on hiding loop hierarchies in an operator Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-17 19:20 +0200

csiph-web