From Newsgroup: comp.lang.misc

Luckily the Genie provides some string manipulation functions
* PROC grep in string
* PROC grep in substring
* PROC sub in string
(see chapter "Regular expressions in string manipulation").

Being used to string processing from other languages there's
some functionality missing, as I noticed with my recreational
activities. So (based on above grep function) I had to write
some more basic regexp string functions that I needed myself.
http://random.gridbug.de/split.a68
http://random.gridbug.de/match.a68
(Only marginally tested; use at own risk.)

One thing that bothered me, though, was that for PROC split
I needed a two-pass process. The reason for that is that it's
(to my knowledge) not possible to simply append to a 'FLEX'
array, so that (to declare the result array; see # <<<<<< # )
I first needed a separate pass to determine the number of its
elements.

Code excerpt as follows...

PROC split = (STRING str, STRING sep) [] STRING :
[...]
ELSE # split on regexp separator #
INT pat_start, pat_end;
INT count := 1; # one more value than separators #
# pass 1: count separators #
STRING s := str;
WHILE grep in string (sep, s, pat_start, pat_end) EQ 0 DO
count PLUSAB 1;
s := s [pat_end + 1 : ]
OD;
[count] STRING result; # <<<<<< #
# pass 2: assign values #
s := str;
FOR i WHILE grep in string (sep, s, pat_start, pat_end) EQ 0 DO
result [i] := s [1 : pat_start - 1];
s := s [pat_end + 1 : ]
OD;
result [count] := s [1 : ];
result
FI


Any suggestions how to (sensibly) avoid a two-pass process?

Janis
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 26/08/2025 05:47, Janis Papanagnou wrote:
[...]

One thing that bothered me, though, was that for PROC split
I needed a two-pass process. The reason for that is that it's
(to my knowledge) not possible to simply append to a 'FLEX'
array,

Correct. "FLEX" does not mean "do anything you like to this
array"!

so that (to declare the result array; see # <<<<<< # )
I first needed a separate pass to determine the number of its
elements.

[...]

Any suggestions how to (sensibly) avoid a two-pass process?

(a) You could declare the "result" array before the first pass,
giving it as many rows as the maximum possible [apart from edge effects,
that's the length of "str" divided by the minimum length of the pattern matched]. Then you can fill in rows of "result" as you find them, and
for the final result return the slice "result [ : count ]".

(b) You could construct a list of the strings found [eg,
"MODE STRINGLIST = STRUCT (REF STRING element, REF STRINGLIST next);",
and add a new element to the list whenever you find a match. Then the
result is constructed by traversing the list. I've used a "REF STRING"
rather than a "STRING" to avoid copying each string twice.

Which of these is better will depend on the expected sizes, so
I'd guess that some experimentation would be in order. Details in both
cases left as an exercise.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Spindler
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 27.08.2025 22:22, Andy Walker wrote:

On 26/08/2025 05:47, Janis Papanagnou wrote:
[...]

One thing that bothered me, though, was that for PROC split
I needed a two-pass process. The reason for that is that it's
(to my knowledge) not possible to simply append to a 'FLEX'
array,

Correct. "FLEX" does not mean "do anything you like to this
array"!

so that (to declare the result array; see # <<<<<< # )
I first needed a separate pass to determine the number of its
elements.

[...]

Any suggestions how to (sensibly) avoid a two-pass process?

(a) You could declare the "result" array before the first pass,
giving it as many rows as the maximum possible [apart from edge effects, that's the length of "str" divided by the minimum length of the pattern matched]. Then you can fill in rows of "result" as you find them, and
for the final result return the slice "result [ : count ]".

(b) You could construct a list of the strings found [eg,
"MODE STRINGLIST = STRUCT (REF STRING element, REF STRINGLIST next);",
and add a new element to the list whenever you find a match. Then the
result is constructed by traversing the list. I've used a "REF STRING" rather than a "STRING" to avoid copying each string twice.

Thanks. - I see that we cannot ("sensibly") avoid bulky or somewhat
less efficient code here. - So I'll stay with my two-pass algorithm
which appears to me to be the clearest implementation (and without
much code overhead) as a compromise (in the light of the possible alternatives).

BTW; WRT your list suggestion. I implemented a list for some other
Algol 68 application. Of course with my OO background I wanted some
generic form that could be used (without reimplementation for other applications) in many contexts. It seems nearly impossible without
genericity and inheritance in Algol 68. (A similar attempt I tried
for a flexible hashmap for a 'map' type.) I saw that solutions on
the Internet are also type/application specific. - How do you model
such things in Algol 68?

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 28/08/2025 06:51, Janis Papanagnou wrote:

BTW; WRT your list suggestion. I implemented a list for some other
Algol 68 application. Of course with my OO background I wanted some
generic form that could be used (without reimplementation for other applications) in many contexts. It seems nearly impossible without
genericity and inheritance in Algol 68. (A similar attempt I tried
for a flexible hashmap for a 'map' type.) I saw that solutions on
the Internet are also type/application specific. - How do you model
such things in Algol 68?

With difficulty! Sorry. There was a proposal to add modals
[variable modes] to A68 [see Algol Bulletin 37 pp 26-29, available
on the web at

https://archive.computerhistory.org/resources/text/algol/algol_bulletin/A37/P43.HTM

] which would have enabled generic list processing and the like, but
as far as I know it has never been implemented in A68. I mentioned it
to Marcel as a possible extension to A68G, but he didn't bite. On the
other hand, the immediately preceding paper in AB 37 [same URL but with
42 instead of 43] was about partial parametrisation, which Marcel /did/
add to A68G. So perhaps if you ask nicely ....
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Praetorius
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 29.08.2025 02:06, Andy Walker wrote:

On 28/08/2025 06:51, Janis Papanagnou wrote:

BTW; WRT your list suggestion. I implemented a list for some other
Algol 68 application. Of course with my OO background I wanted some
generic form that could be used (without reimplementation for other
applications) in many contexts. It seems nearly impossible without
genericity and inheritance in Algol 68. (A similar attempt I tried
for a flexible hashmap for a 'map' type.) I saw that solutions on
the Internet are also type/application specific. - How do you model
such things in Algol 68?

With difficulty! Sorry.

Okay. We have to live with what we got. :-)

There was a proposal to add modals
[variable modes] to A68 [...snip link...] which would have enabled
generic list processing and the like, but as far as I know it has
never been implemented in A68.

Thanks for the references.

It's certainly too late to complain now. :-/

I mentioned it
to Marcel as a possible extension to A68G, but he didn't bite. On the
other hand, the immediately preceding paper in AB 37 [same URL but with
42 instead of 43] was about partial parametrisation, which Marcel /did/
add to A68G. So perhaps if you ask nicely ....

Don't count on me here. - I had quite some communication with Marcel
during the past months, and most of it was a one-way communication.
Many "bugs or suggestions" were mostly ignored; and that's okay -
I don't want to beset and burden him with such; for him Genie is a
"spare time project" and for me it's a recreational use of Genie -
so it would be unfair asking him for huge or fundamental extensions.

I'd like to discuss with you some of these requests (maybe another
day); I'd be interested to hear your opinions...

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 30/08/2025 04:54, Janis Papanagnou wrote:
[...]

I'd like to discuss with you some of these requests (maybe another
day); I'd be interested to hear your opinions...

So would I. [:-)]
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Strauss
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 30.08.2025 21:41, Andy Walker wrote:

On 30/08/2025 04:54, Janis Papanagnou wrote:
[...]

I'd like to discuss with you some of these requests (maybe another
day); I'd be interested to hear your opinions...

So would I. [:-)]

Glad to hear! :-)

Give me some time; the recent posts demanded too much of my
"Copious Free Time", I fear. ;-)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2