On 18/11/2021 13:25, Bart wrote:
> On 17/11/2021 20:56, Andy Walker wrote:

>>      Style wars are always unedifying, and are usually caused by
>> unfamiliarity with the language.  If you don't like the style, you
>> can always run the source through a pretty-printer.
>
> In this case, it's simply poor.

I created a version in my own A68 style, shown below.

* I've dispensed with the extra high precision; it only works with LONG
LONG INT

* I've changed MIN to a function

* It doesn't have that funny +:= op

* I've had to use a fixed size array as I couldn't figure out how FLEX
is supposed to work. (It's perhaps not as 'flex' as the name suggests if
you can only assign a whole new array, rather than incrementally grow an
array.)

---------------------------------------------------
PROC min = (LONG INT a,b)LONG INT: (a<b | a | b);

PROC hamm = (INT n)LONG INT:
BEGIN
CASE n
IN 1, 2, 3, 4, 5, 6, 8, 9, 10, 12 # n = 1..10 maps to these #
OUT
[1:2000]LONG INT h; h[1]:=1;
INT hsize:=1;
LONG INT m2:=2, m3:=3, m5:=5;
INT i:=1, j:=1, k:=1;

TO n-1 DO
hsize +:= 1;
h[hsize] := min(min(m2,m3),m5);
IF h[hsize] = m2 THEN m2 := 2*h[i +:= 1] FI;
IF h[hsize] = m3 THEN m3 := 3*h[j +:= 1] FI;
IF h[hsize] = m5 THEN m5 := 5*h[k +:= 1] FI
OD;
h[hsize]
ESAC
END;

FOR k TO 20 DO
print ((hamm(k), newline))
OD;
print ((hamm(1691), newline))

On 18/11/2021 13:25, Bart wrote:
[I wrote:]
>> If you want to invent another language called A68Bart, feel free,
> I did that in 1981/82! I called it M.

Mine, from around the same period, was called Portuguese,
being part of a chain starting from Pascal == Albanian, via Belgian,
Chinese, ... and intended to reach Zulu == Algol, each language being
easily derived from its predecessor and replacing misfeatures of
Pascal by features of Algol. It ran out of steam when our computer
was replaced and the Amsterdam Compiler Kit wasn't, but I'd done all
the easy bits by then anyway.

[Marcel's "Hamming" program:]
>>      Style wars are always unedifying, and are usually caused by
>> unfamiliarity with the language.  If you don't like the style, you
>> can always run the source through a pretty-printer.
> In this case, it's simply poor.

In your opinion. Marcel is not here to defend himself,
and his layout differs from mine, but [in my opinion] that does
not, of itself, make his "poor". Just different.

> A pretty printer might change the
> layout and indent things more consistently, but it would still leave
> those OP definitions in the middle of the algorithm,

Close to where they're used. Algol, unlike Pascal and some
C, doesn't force you into a rigid "all declarations first" style,
which allows you more freedom. As above, it's at least partly a
matter of familiarity, and partly a general desire to get related
concepts onto one screen.

> or leave alone
> this puzzling style of declaration (abbreviated):
>     SERIES h:=1, UNT m2:=2, INT i:=3;
> The puzzle was the use of commas instead of semicolons to separate
> distinct declarations.

Well, you've made it more of a "puzzle" by putting them all
on one line, where the original had them on separate lines. But
again it's largely what you're used to. Marcel clearly felt, to a
greater extent than you do, that those were related declarations
[like a record specification but without formalising the type].

> Even if the language allows it, you need to
> consider clarity especially in a textbook aimed at people learning
> the language.

You found it unclear only because your conditioned rules
for whether declarations should be separated by comma or semicolon
differ from those of Algol [and probably from those of C]. Matter
of experience, again. Beginners don't share your conditioning or
[therefore] your puzzlement.

[... and later:]> I created a version in my own A68 style, shown below.
> * I've dispensed with the extra high precision; it only works with
> LONG LONG INT
Your code, as given, uses only "LONG INT", which is why
you can't get to "hamm(1000000)".

> * I've changed MIN to a function
> * It doesn't have that funny +:= op
> * I've had to use a fixed size array as I couldn't figure out how
> FLEX is supposed to work. (It's perhaps not as 'flex' as the name
> suggests if you can only assign a whole new array, rather than
> incrementally grow an array.)

That, in essence, is the problem with "FLEX". It has almost
no practical use except in the case of strings. It would have been
a prime candidate for deletion in a new revision of Algol, with some
new syntax instead for strings. Somewhat of a pity, as there is no
logical reason why strings should be so very different from arrays of
characters. But there are reasons why, perhaps, incremental growth
and shrinkage should be built in.

> ---------------------------------------------------
> PROC min = (LONG INT a,b)LONG INT: (a<b | a | b);

** You really need to go to LONG LONG INT, otherwise you can't go
beyond "hamm(75767)", far short of the "hamm(1000000)" asked for.
Note that "hamm(1691)", the other one asked for, is the last
Hamming number before "maxint", which is presumably why it was
chosen as a test case.

> PROC hamm = (INT n)LONG INT:
> BEGIN

** This "BEGIN ... END" pair is redundant. Matter of style!

> CASE n
> IN 1, 2, 3, 4, 5, 6, 8, 9, 10, 12 # n = 1..10 maps to these #

** I don't see the point in you [and Marcel] picking out the first 10
cases. They're essentially instant anyway. OTOH, there ought to
be a test that "n >= 1".

> OUT
> [1:2000]LONG INT h; h[1]:=1;

** The buffer size needs to be [at least] "n" for your code. By using
a circular buffer [see my version below], you can cut that to about
n^(2/3), which is a very substantial saving if "n" ~ 10^9 or so. As
noted elsewhere, there are much more efficient ways again, esp for
"n" really large. [It's not just the number of elements, eg 10^6 vs
10^9, but also each element is large if it's high-precision.]

> INT hsize:=1;
> LONG INT m2:=2, m3:=3, m5:=5;
> INT i:=1, j:=1, k:=1;
>
> TO n-1 DO
> hsize +:= 1;
> h[hsize] := min(min(m2,m3),m5);
> IF h[hsize] = m2 THEN m2 := 2*h[i +:= 1] FI;
> IF h[hsize] = m3 THEN m3 := 3*h[j +:= 1] FI;
> IF h[hsize] = m5 THEN m5 := 5*h[k +:= 1] FI
> OD;
> h[hsize]
> ESAC
> END;
>
> FOR k TO 20 DO
> print ((hamm(k), newline))
> OD;
> print ((hamm(1691), newline))

My version: [I had seen Marcel's, but not yours when I wrote it. I
use "INC" rather than "+:=", so that indices wrap on reaching "upb".
I haven't bothered to implement faster methods; it's not /that/
interesting a problem, and it's fast enough when n ~ 10^6. May be
worth noting that ~95% of the time [for n ~ 10^6], x2 == x3 == x5,
so there is perhaps a small but real optimisation possible. In case
you ever try this with a real A68 compiler, note that A68G has an
extension whereby "INTs" are lengthened where appropriate. Enjoy.]

=== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ===

PR precision=65 PR # enough for n ~ 10^6 #

PROC hamm = (INT n) LONG LONG INT:
IF n <= 0
THEN print (("Error: hamm called with parameter ",
whole (n, 0), " [<= 0]", newline));
stop
ELSE INT upb = ENTIER exp(ln(n)*2/3 + 1); # allows a small margin #
PRIO MIN = 5;
OP MIN = (LONG LONG INT a, b) LONG LONG INT: (a < b | a | b ),
INC = (REF INT i) INT: ( i = upb | i := 1 | i +:= 1 );
[upb] LONG LONG INT store;
store[1] := 1;
INT i2 := 1, i3 := 1, i5 := 1, k := 1;
LONG LONG INT x2 := 2, x3 := 3, x5 := 5;
TO n-1 DO store [INC k] := x2 MIN x3 MIN x5;
( x2 <= store[k] | x2 := 2 * store [INC i2] );
( x3 <= store[k] | x3 := 3 * store [INC i3] );
( x5 <= store[k] | x5 := 5 * store [INC i5] )
OD;
store[k]
FI;

FOR i TO 20 DO print (" " + whole (hamm(i), 0)) OD;
print (( newline, whole (hamm(1691), 0), newline ));
print (( whole (hamm (1000000), 0), newline ))

=== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ===

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Kontski

On 20/11/2021 01:11, Andy Walker wrote:
> On 18/11/2021 13:25, Bart wrote:
> [I wrote:]
>>> If you want to invent another language called A68Bart, feel free,
>> I did that in 1981/82! I called it M.
>
>     Mine, from around the same period, was called Portuguese,
> being part of a chain starting from Pascal == Albanian, via Belgian,
> Chinese, ... and intended to reach Zulu == Algol, each language being
> easily derived from its predecessor and replacing misfeatures of
> Pascal by features of Algol.

Misfeatures?

I rated Pascal above Algol68 (but I was never able to use the latter
then). Because I could understand a Pascal program better, and therefore
could write Pascal more easily. I could also easily see how things might
be implemented.

But I rated Algol68 syntax above Pascal's.

>> this puzzling style of declaration (abbreviated):
>>      SERIES h:=1, UNT m2:=2, INT i:=3;
>> The puzzle was the use of commas instead of semicolons to separate
>> distinct declarations.
>
>     Well, you've made it more of a "puzzle" by putting them all
> on one line,

To highlight what it is doing.

>     You found it unclear only because your conditioned rules
> for whether declarations should be separated by comma or semicolon
> differ from those of Algol [and probably from those of C].  Matter
> of experience, again.  Beginners don't share your conditioning or
> [therefore] your puzzlement.

Too many things are lists when they don't need to be.

I also use this pattern (declarations separated by commas), but only in
parameter lists, which are usually written on one line. But I'm slightly
uneasy about it, and might require a semicolon separator at some point
to match similar syntax elsewhere.

> [... and later:]> I created a version in my own A68 style, shown below.
>> * I've dispensed with the extra high precision; it only works with
>> LONG LONG INT
>     Your code, as given, uses only "LONG INT", which is why
> you can't get to "hamm(1000000)".

I wanted to get away from "UNT" and "PR2" (and also from all those
leading spaces which is a silly way of printing wide numbers).

Hamm(1691) was supposed to be representable in 32 bits, but I got an
overflow with INT; I had to use LONG INT. (LONG LONG was a typo.)

To do hamm(1000000), I would have needed not only LONG LONG INT, but
also PR 100; this part seems a little too trial and error.

> ** This "BEGIN ... END" pair is redundant.  Matter of style!
You clearly don't believe in properly delimiting function bodies so that
they don't blend into surrounding code. This was one problem (of many)
with Python's indent syntax.

>>          CASE n
>>          IN 1, 2, 3, 4, 5, 6, 8, 9, 10, 12   # n = 1..10 maps to these #
>
> ** I don't see the point in you [and Marcel] picking out the first 10
>    cases.  They're essentially instant anyway.  OTOH, there ought to
>    be a test that "n >= 1".

I copied this bit but eventually figured out it was pointless, as the
main algorithm works fine for N=1..10.

But it had also caused me grief as I'd forgotten how Algol68's CASE worked.

It's more like my N-way select, which I only implement now in this form:

(n | a, b, c | z)

with no 'long' form which would have looked like this:

select n then a, b, c else z end

as I considered the construct unsuitable for longer, multiline code. You
too easily lose connection between 1, 2, 3, ... and the corresponding
expression.

> My version:  [I had seen Marcel's, but not yours when I wrote it.  I
> use "INC" rather than "+:=", so that indices wrap on reaching "upb".
> I haven't bothered to implement faster methods;  it's not /that/
> interesting a problem, and it's fast enough when n ~ 10^6.  May be
> worth noting that ~95% of the time [for n ~ 10^6], x2 == x3 == x5,
> so there is perhaps a small but real optimisation possible.  In case
> you ever try this with a real A68 compiler, note that A68G has an
> extension whereby "INTs" are lengthened where appropriate.  Enjoy.]
>
> === 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ===
>
> PR precision=65 PR  # enough for n ~ 10^6 #
>
> PROC hamm = (INT n) LONG LONG INT:
>    IF n <= 0
>      THEN print (("Error:  hamm called with parameter ",
>                    whole (n, 0), " [<= 0]", newline));
>           stop
>      ELSE INT upb = ENTIER exp(ln(n)*2/3 + 1); # allows a small margin #
>           PRIO MIN = 5;
>           OP MIN = (LONG LONG INT a, b) LONG LONG INT: (a < b | a | b ),
>              INC = (REF INT i) INT: ( i = upb | i := 1 | i +:= 1 );
>           [upb] LONG LONG INT store;
>              store[1] := 1;
>           INT i2 := 1, i3 := 1, i5 := 1, k := 1;
>           LONG LONG INT x2 := 2, x3 := 3, x5 := 5;
>           TO n-1 DO store [INC k] := x2 MIN x3 MIN x5;
>                     ( x2 <= store[k] | x2 := 2 * store [INC i2] );
>                     ( x3 <= store[k] | x3 := 3 * store [INC i3] );
>                     ( x5 <= store[k] | x5 := 5 * store [INC i5] )
>                  OD;
>           store[k]
>    FI;
>
> FOR i TO 20 DO print (" " + whole (hamm(i), 0)) OD;
> print (( newline, whole (hamm(1691), 0), newline ));
> print (( whole (hamm (1000000), 0), newline ))

This is more performant than the version in the book. It does 100 x
hamm(1691) in about 1 second instead of 20 seconds (17 with PR 65).

I wasn't able to do hamm(10000000) on that old version, but yours
manages it in around 7 seconds.

My dynamic version (not Algol) does it one second, making use of bignum
types, and 10 million in about 10 seconds.

I did try manipulating the list lower abound to keep memory down, but it
made no difference on those. It did allow hamm(100 million) (in 3 mins
IIRC) otherwise it would have run out of memory.

On 20/11/2021 16:51, Bart wrote:
[I wrote:]
>> [...] each language being
>> easily derived from its predecessor and replacing misfeatures of
>> Pascal by features of Algol.
> Misfeatures?

If you aren't aware that Pascal has misfeatures, that accounts
for a lot! You could start with Brian Kernighan's famous "Why Pascal
is not my favourite language". I don't agree with everything he says,
but it's a good start.

> I rated Pascal above Algol68 (but I was never able to use the latter
> then). Because I could understand a Pascal program better, and
> therefore could write Pascal more easily. I could also easily see how
> things might be implemented.

Ie, you were more familiar with Pascal. It shows. If you
had been taught Algol as your first language, you would have found
Pascal v frustrating.

> But I rated Algol68 syntax above Pascal's.

Despite not knowing it!

> Too many things are lists when they don't need to be.

The point is not whether things need to be lists, but
whether they need not to be. Your puzzlement again stems from
lack of familiarity.

> I also use this pattern (declarations separated by commas), but only
> in parameter lists, which are usually written on one line. But I'm
> slightly uneasy about it, and might require a semicolon separator at
> some point to match similar syntax elsewhere.

There is no incredibly interesting distinction between, say,
"int i, j, real x" when it's part of a parameter specification, or
when it's part of a structure definition, or when it's a declaration.
So the question is not really whether commas should be allowed, but
why semicolons should be required. Matching other syntax is one
possible reason, so is legibility, so is avoiding ambiguities. None
of those apply to ordinary declarations.

> I wanted to get away from "UNT" and "PR2" (and also from all those
> leading spaces which is a silly way of printing wide numbers).

I expect "UNT" and "PR2" are meaningful in Dutch .... If
you want to control the number of leading spaces more closely, then
you should perhaps switch to formatted transput? But I find the
use of "whole" [and its relatives "fixed" and "float"], RR10.3.2.1,
to be adequate for most purposes.

> Hamm(1691) was supposed to be representable in 32 bits, but I got an
> overflow with INT; I had to use LONG INT.

Hamm(1691) /is/ representable in 32 bits, but the 1692nd
isn't, so the calculation you used overflows when you set up for
the next number. If you really want to pursue this, the trick is
to stop filling the array before calculating the next "2*x2".
Note that at least you got an overflow, not a calculation that
proceeded with incorrect results -- you couldn't expect Algol to
know that the calculation was about to halt before using them!

> To do hamm(1000000), I would have needed not only LONG LONG INT, but
> also PR 100; this part seems a little too trial and error.

Algol doesn't have a generic "BIGNUM", so you get either
to write one yourself [not that difficult, but more work than just
using a high-enough precision] or to use "LONG LONG INT" within
its limitations. It's reasonably easy, given a little theory, to
estimate "hamm(1000000)", but [perhaps sadly] the precision in
A68G has to be a numerical constant, so you get to estimate it
rather than having the program do so. Could no doubt manage that
with a pre-processor [eg a script/program to estimate the required
precision and call "a68g" with an appropriate parameter].

>> ** This "BEGIN ... END" pair is redundant.  Matter of style!
> You clearly don't believe in properly delimiting function bodies so
> that they don't blend into surrounding code. This was one problem (of
> many) with Python's indent syntax.

Contrariwise, I find it curious that you understand
"PROC [blah]: BEGIN ... END;", and "PROC [blah]: (...);" but
not "PROC [blah]: CASE ... ESAC;", "PROC [blah]: IF ... FI;"
nor [presumably] "PROC [blah]: i+j;" [in each case assumed to
have appropriate indentation and blank lines]. The syntax is
that the procedure body is a unit; it's quite rare in Algol
that a unit /has/ to be delimited by "BEGIN ... END", even
merely for legibility, unlike in Pascal. Again, it's largely
a matter of familiarity.

[...]
> I did try manipulating the list lower abound to keep memory down, but
> it made no difference on those. It did allow hamm(100 million) (in 3
> mins IIRC) otherwise it would have run out of memory.

Yes, it makes negligible difference to the timing, only
to memory consumption. But by the time you're up to "n" > 10^8,
the full array occupies a gigabyte for each ten bytes occupied
by a "bignum", which is quite a lot when you're dealing with
really large Hamming numbers. Saving a factor of ~1000 is then
worthwhile, as gigabytes shrink to megabytes. [More efficient
methods save a further huge factor in both space and time, but
not within ~24 lines of code.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Wolf

On 21/11/2021 19:06, Andy Walker wrote:
> On 20/11/2021 16:51, Bart wrote:
> [I wrote:]
>>> [...] each language being
>>> easily derived from its predecessor and replacing misfeatures of
>>> Pascal by features of Algol.
>> Misfeatures?
>
>     If you aren't aware that Pascal has misfeatures, that accounts
> for a lot!  You could start with Brian Kernighan's famous "Why Pascal
> is not my favourite language".  I don't agree with everything he says,
> but it's a good start.

I haven't written Pascal since 1980 I think, so I've forgotten some
limitations. I do know that there were problems in having an array type
not limited to a specific length.

Since then, I've had so much experience in creating languages to do real
work, that tweaking a 1980s version of Pascal so that it can be a proper
working language wouldn't seem an inordinate amount of effort.

BTW Point 5 of that paper applies to Algol68 too: semicolons as separators.

>
>> I rated Pascal above Algol68 (but I was never able to use the latter
>> then). Because I could understand a Pascal program better, and
>> therefore could write Pascal more easily. I could also easily see how
>> things might be implemented.
>
>     Ie, you were more familiar with Pascal.  It shows.  If you
> had been taught Algol as your first language, you would have found
> Pascal v frustrating.

I was taught Algol60 as a first language. I went off to work on a
placement, came back and found they'd switched to Pascal.

I found Pascal cruder and lower level than Algol (which had first class
flex strings for example), but it also richer with lots of interesting
new ideas.

>> But I rated Algol68 syntax above Pascal's.
>
>     Despite not knowing it!

I knew enough to see that it had solved the BEGIN-END problem. That was
a bugbear with Pascal: add a second statement inside THEN-ELSE, and now
you need to write THEN-BEGIN-END-ELSE.

It was a bloody nuisance. And where are you going to put BEGIN-END? You
might need a new indent level.

Brace languages have the same problem with {-}.

>     There is no incredibly interesting distinction between, say,
> "int i, j, real x" when it's part of a parameter specification, or
> when it's part of a structure definition, or when it's a declaration.
> So the question is not really whether commas should be allowed, but
> why semicolons should be required.

A better question is what is the difference between comma and semicolon
in Algol68?

I use commas to separate list elements, but an element of a list can be
what I think Algol68 calls an /sunit/ (statements separated with
semicolons; ie. not a list!).

That leads to a comma, a weaker, more subordinate symbol than semicolon,
being used as the more significant separator!

My syntax generally transforms newlines into semicolons. But where I
have a multiline list:

[]int A = (
10,
20,
....
99990)

I still have to write all the commas, with a special case at the end.

This part of my syntax will need to be reviewed I think. I don't like
using commas across multiple lines. Opening and closing parenthese
aren't too great idea.

Some of this has been done; I can write:

record date = (var d, m, y)

or I can write it as:

record date =
var d, m, y
end

which is better suited for multiple lines.

On 21/11/2021 20:12, Bart wrote:
> A better question is what is the difference between comma and
> semicolon in Algol68?

In very broad terms, "A; B" means "A" and then "B", while
"A, B" means "A" collaterally with "B". For more details, you
would need to look at the RR, where ";" appears as the "go on
symbol" and "," as the "and also symbol".

> I use commas to separate list elements, but an element of a list can
> be what I think Algol68 calls an /sunit/ (statements separated with
> semicolons; ie. not a list!).

I don't know where you've seen "sunit", but it's not part
of the RR. You seem perhaps to be thinking of a "series"? See
RR3.2.1b.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Grieg