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.
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.
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.)
The simplest workaround seems to be to
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".
[...] 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.
On 01.11.2025 21:54, I wrote:
The simplest workaround seems to be toI had intended to avoid "spurious" declarations, but to keep the later
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".
code's logic clearer it might be worth to follow that path.
On 02/11/2025 06:33, Janis Papanagnou wrote:
On 01.11.2025 21:54, I wrote:
The simplest workaround seems to be toI had intended to avoid "spurious" declarations, but to keep the later
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".
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!
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 toI had intended to avoid "spurious" declarations, but to keep the later
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".
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.
[...]
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 toI had intended to avoid "spurious" declarations, but to keep the later >>>> code's logic clearer it might be worth to follow that path.
declare "pp" in the way you've declared "p", and then declare
"[] PROC BOOL p = pp[@0];".
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
[...]
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.
On 02/11/2025 11:44, bart wrote:
I couldn't get this to work:
[0:3]INT a := (10, 20, 30);
Well, no. You are trying to assign a row of three integers to a row of four integer variables with a different lower bound.
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];
You still have the 3 vs 4 problem, but you've also run into an obscure part of A68 syntax. "(10, 20, 30)" could be a row of integers.
It could also be a structure with three fields [not necessarily integers,
as "10" [eg] could be widened to a real or a complex]. In more general cases [such as Janis's original example] there are many more things that
that RHS could, in principle, be. Without the "[@0]", the row display is commonly in a strong syntactic position, meaning that the compiler knows exactly what type of object it is required to be and can, if necessary,
apply a number of coercions to convert its mode as necessary. With the "[@0]", the row is in a position where the available coercions are more limited [the construct has become a "slice"]. That's why the two "workarounds" that Janis has given you work; in one case he supplies an explicit array to be sliced, and in the other he uses a cast to put the
row back into a strong position.
It seems a weak spot in the language.
Sadly, it's now too late to ask Charles Lindsey why it was
done that way. I did once ask him, but I've forgotten what the answer was; sorry! There /was/ a reason!
On 03/11/2025 00:42, Andy Walker wrote:
On 02/11/2025 11:44, bart wrote:
I couldn't get this to work:
[0:3]INT a := (10, 20, 30);
Well, no. You are trying to assign a row of three integers to a
row of four integer variables with a different lower bound.
That was my mistake. I'd forgotten that in Algol 68, The '3' in '[0:3]'
is the upper bound not the length.
(In my verson of the syntax, it is either [lwb..upb], or [lwb:length],
with the length being optional for unbounded arrays, or where it is set
by the initialisation data.)
But if I adjust it to [0:2] to match the (10, 20, 30), then the
underlying problem is still there.
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];
You still have the 3 vs 4 problem, but you've also run into an
obscure part of A68 syntax. "(10, 20, 30)" could be a row of integers.
It could also be a structure with three fields [not necessarily integers,
as "10" [eg] could be widened to a real or a complex]. In more general
cases [such as Janis's original example] there are many more things that
that RHS could, in principle, be. Without the "[@0]", the row display is
commonly in a strong syntactic position, meaning that the compiler knows
exactly what type of object it is required to be and can, if necessary,
apply a number of coercions to convert its mode as necessary. With the
"[@0]", the row is in a position where the available coercions are more
limited [the construct has become a "slice"]. That's why the two
"workarounds" that Janis has given you work; in one case he supplies an
explicit array to be sliced, and in the other he uses a cast to put the
row back into a strong position.
I was trying another experiment: a 1-element initialiser, but on the way there, came across this:
[]INT a := (10, 20);
It says 'Actual bounds expected'. So it can't work it out for itself?
That's very poor; I may have 283 items, do I have to count them all (or
making closer and closer guesses via trial and error)?
Then do the same when they change.
Sticking [@1] at the end didn't help.
What's coming across is that they spent an awful lot of time preparing a beautifully consistent Revised Report, but not enough running actual, real-lfe programs!
[...]
On 03.11.2025 16:03, bart wrote:
You either don't read the answers given, or don't try to understandthem!
Starting indexing at 1 is anyway the default, so there's not muchpoint doing that with your examples here.
You've in comp.lang.c proven countless times that you have no idea
what real "real-life programs" are.
And now you're also infesting comp.lang.misc with your tons of complaints-posts in band-worm threads and self-advertisement for
"your languages"... *sigh* - Please don't continue that here!
On 03.11.2025 16:03, bart wrote:
[]INT a := (10, 20);
It says 'Actual bounds expected'. So it can't work it out for itself?
If you're intending to assign values to variables you define them
[2] INT a := (10, 20);
or if you have an identity relation (a "constant") you may write
[] INT b = (10, 20);
Either way, you'd complain; because it's not like "your languages"
work.
That's very poor; I may have 283 items, do I have to count them all (or
If you are enumerating an initializer list of 283(!) elements but
pretend to be too lazy to tell how many there
If you'd _really_ be interested about Algol 68 you should read a
textbook.
On 03/11/2025 15:40, Janis Papanagnou wrote:
On 03.11.2025 16:03, bart wrote:
[]INT a := (10, 20);
It says 'Actual bounds expected'. So it can't work it out for itself?
If you're intending to assign values to variables you define them
[2] INT a := (10, 20);
or if you have an identity relation (a "constant") you may write
[] INT b = (10, 20);
OK, that takes care of most use-cases where you have initialiser values.
But why doesn't it work with ":="?
Either way, you'd complain; because it's not like "your languages"
work.
Or like C:
const int a[] = {10, 20, ...};
int b[] = {10, 20, ...};
Neither of these require you to count the elements.
That's very poor; I may have 283 items, do I have to count them all (or
If you are enumerating an initializer list of 283(!) elements but
pretend to be too lazy to tell how many there
The '283' represents some unknown number of initialiser values.
The
compiler will know how many there are; there's no need for you to have
to as well!
[...]
If you'd _really_ be interested about Algol 68 you should read a
textbook.
I was really interested at one time, and I learnt about it from a book.
Clearly, you don't care for language design at all.
On 03.11.2025 18:32, bart wrote:
The '283' represents some unknown number of initialiser values.
Nonsense; if you have an initializer the number isn't unknown.
I was really interested at one time, and I learnt about it from a book.
Then I wonder about your problems knowing or understanding what
was even explicitly explained to you in the posts of the thread.
On 03.11.2025 18:00, bart wrote:
Clearly, you don't care for language design at all.
Au contraire!
You are missing so many things - even if explicitly and multiply
having been pointed to! - that I'm not astonished that you missed
that too!
You've regularly shown that you're so focused on [less important]
details that you're regularly missing the big picture! - This could
be seen for software projects, components, design, environments,
standards, methods, and much more...
Janis
On 03/11/2025 19:28, Janis Papanagnou wrote:
On 03.11.2025 18:32, bart wrote:
The '283' represents some unknown number of initialiser values.
Nonsense; if you have an initializer the number isn't unknown.
It will be known to the compiler after parsing; it might not be known to
you!
By coincidence, here is some init data I had to generate today:
0x55, 0x48, 0x8B, 0xEC, 0x48, 0x83, 0xEC, 0x20, 0x48, 0x89, 0x4D, 0x10,
0x48, 0x89, 0x55, 0x18, 0x4C, 0x89, 0x45, 0x20, 0x4C, 0x89, 0x4D, 0x28,
0x33, 0xC0, 0x48, 0x89, 0x45, 0xF0, 0x8B, 0x45, 0x20, 0x83, 0xE0, 0x01,
0x48, 0x85, 0xC0, 0x74, 0x0B, 0xB8, 0x08, 0x00, 0x00, 0x00, 0x48, 0x89,
0x45, 0xF0, 0x6A, 0x00, 0x48, 0x8B, 0x45, 0x20, 0x48, 0xC1, 0xE0, 0x03,
0x48, 0x01, 0x45, 0xF0, 0x48, 0x8B, 0x45, 0x20, 0x48, 0x89, 0x45, 0xE8,
0x48, 0x8B, 0x45, 0xE8, 0x48, 0x83, 0xF8, 0x01, 0x0F, 0x8C, 0x25, 0x00,
0x00, 0x00, 0x48, 0x8B, 0x45, 0x18, 0x4C, 0x8B, 0x55, 0xE8, 0x4A, 0x8B,
0x44, 0xD0, 0xF8, 0x48, 0x89, 0x45, 0xF8, 0xFF, 0x75, 0xF8, 0x48, 0x8B,
0x45, 0xE8, 0x48, 0xFF, 0xC8, 0x48, 0x89, 0x45, 0xE8, 0x48, 0x83, 0xF8,
0x01, 0x7D, 0xDB, 0x48, 0x8B, 0x0C, 0x24, 0xF3, 0x0F, 0x7E, 0x04, 0x24,
0x48, 0x8B, 0x54, 0x24, 0x08, 0xF3, 0x0F, 0x7E, 0x4C, 0x24, 0x08, 0x4C,
0x8B, 0x44, 0x24, 0x10, 0xF3, 0x0F, 0x7E, 0x54, 0x24, 0x10, 0x4C, 0x8B,
0x4C, 0x24, 0x18, 0xF3, 0x0F, 0x7E, 0x5C, 0x24, 0x18, 0x48, 0x8B, 0x45,
0x10, 0x48, 0xFF, 0xD0, 0x48, 0x03, 0x65, 0xF0, 0x44, 0x8A, 0x55, 0x28,
0x45, 0x22, 0xD2, 0x74, 0x05, 0x66, 0x48, 0x0F, 0x7E, 0xC0, 0x48, 0x89,
0x45, 0xF8, 0x48, 0x8B, 0x45, 0xF8, 0x48, 0x83, 0xC4, 0x20, 0x5D, 0xC3
(I hope, that when posted, it doesn't wrap.)
This is meant to be incorporated into some program source code. To avoid annoying you, let's pretend that's C, then I'd need to book-end it like
this:
char data[] = {
<block of text from above>
};
Now, you're saying I ought to know what goes inside '[]'.
Well, not
really. Perhaps the program generating that data could print that value.
Or I could count columns and rows and work it out. But I don't really
want to have to hardcode that value inside [].
Maybe I will regenerate that data (perhaps it will be included from some
file that I don't even look at) then I'd have to update the number.
It just shouldn't be necessary.
The largest set of data I've included this way I think was 100M numbers.
That was testing embedding. But I have included actual binary data (eg. images and executables) like this too.
I was really interested at one time, and I learnt about it from a book.
Then I wonder about your problems knowing or understanding what
was even explicitly explained to you in the posts of the thread.
It was about 45 years ago, and I never managed to try it out for real
until A68G came about.
Those decades of real-life experience (whatever your opinions about
that), opened my eyes more to its practicial deficiencies.
It's clearly a language that belongs more in academia.
[...]
On 03/11/2025 20:02, Janis Papanagnou wrote:
On 03.11.2025 18:00, bart wrote:
Clearly, you don't care for language design at all.
Au contraire!
You are missing so many things - even if explicitly and multiply
having been pointed to! - that I'm not astonished that you missed
that too!
You've regularly shown that you're so focused on [less important]
details that you're regularly missing the big picture! - This could
be seen for software projects, components, design, environments,
standards, methods, and much more...
[...]
So, you're saying this is just concentrating on the details? I'd be interested in what the big picture is then.
On 03.11.2025 21:34, bart wrote:
On 03/11/2025 20:02, Janis Papanagnou wrote:
On 03.11.2025 18:00, bart wrote:
Clearly, you don't care for language design at all.
Au contraire!
You are missing so many things - even if explicitly and multiply
having been pointed to! - that I'm not astonished that you missed
that too!
You've regularly shown that you're so focused on [less important]
details that you're regularly missing the big picture! - This could
be seen for software projects, components, design, environments,
standards, methods, and much more...
[...]
So, you're saying this is just concentrating on the details? I'd be
interested in what the big picture is then.
I've named some above and you've documented that all in hundreds of
your posts in comp.lang.c and can read that in the responses.
file that I don't even look at) then I'd have to update the number.
It just shouldn't be necessary.
Those decades of real-life experience (whatever your opinions about that), opened my eyes more to its practicial deficiencies.
It's clearly a language that belongs more in academia.
By coincidence, here is some init data I had to generate today:
[long array of hex machine-code numbers omitted]
On Mon, 3 Nov 2025 20:10:12 +0000, bart wrote:
By coincidence, here is some init data I had to generate today:
[long array of hex machine-code numbers omitted]
If you look at Free Software licences, they have a definition for what “source code” means: it is “the preferred form” for doing development with.
Regardless of whether your project is “Free Software” or not, I’m assuming
that your project tree includes the source program (and necessary build scripts) for generating that long list of random-looking numbers that
nobody in their right mind would want to look at. Otherwise, it’s going to be very hard for your employer to find somebody else to maintain your code
if you should happen to get hit by a bus ...
In which case, why are those numbers being included in your source? I
would generate them from the *real* source (the one that a human would
want to look at) as an automatic part of the build process. That way, any bugs found in that code could be fixed in just one place, and the fix will
be included in the next build without further effort. And the diff for the fix (no doubt with an associated explanatory comment) would be visible in
an easily-understood form to anybody viewing the commit history of your
repo.
This is why we have build scripts. The computer is a wonderful tool, in
its ability to perform tedious, repetitive tasks that we humans do so
badly. This is why we write programs; some of those programs get so
complex (as in your example) that it becomes helpful to write smaller, simpler programs to ease the task of building those bigger, more complex programs, because that’s how we get the computer to help with the process. It’s an extra level of indirection, that lets us ascend higher on the complexity pyramid than we could manage if we didn’t have it.
The bytes were generated from one program, captured into a text file,
then pasted into another source.
On 03/11/2025 20:10, bart wrote:
[...]
[...]
I don't know what causes you to think it an "academic" language -- /apart/ from the unfortunate fact that the first few textbooks on A68 were very
bad, and impractical for proper teaching. [Both Pascal and C fared much better in this regard.]
On 03/11/2025 21:35, Janis Papanagnou wrote:
On 03.11.2025 21:34, bart wrote:
On 03/11/2025 20:02, Janis Papanagnou wrote:
On 03.11.2025 18:00, bart wrote:
Clearly, you don't care for language design at all.
Au contraire!
You are missing so many things - even if explicitly and multiply
having been pointed to! - that I'm not astonished that you missed
that too!
You've regularly shown that you're so focused on [less important]
details that you're regularly missing the big picture! - This could
be seen for software projects, components, design, environments,
standards, methods, and much more...
[...]
So, you're saying this is just concentrating on the details? I'd be
interested in what the big picture is then.
I've named some above and you've documented that all in hundreds of
your posts in comp.lang.c and can read that in the responses.
[...]
So, what am I missing? Enlighten me; [...]
[...]
On 04.11.2025 00:37, bart wrote:
On 03/11/2025 21:35, Janis Papanagnou wrote:
On 03.11.2025 21:34, bart wrote:
On 03/11/2025 20:02, Janis Papanagnou wrote:
On 03.11.2025 18:00, bart wrote:
Clearly, you don't care for language design at all.
Au contraire!
You are missing so many things - even if explicitly and multiply
having been pointed to! - that I'm not astonished that you missed
that too!
You've regularly shown that you're so focused on [less important]
details that you're regularly missing the big picture! - This could
be seen for software projects, components, design, environments,
standards, methods, and much more...
[...]
So, you're saying this is just concentrating on the details? I'd be
interested in what the big picture is then.
I've named some above and you've documented that all in hundreds of
your posts in comp.lang.c and can read that in the responses.
[...]
So, what am I missing? Enlighten me; [...]
Given all the discussions that people had with you of over the past
years, and your obvious inability to see it (or understand it when
hinted), there's no point in wasting time repeating or summarizing
all that for you. - Good luck with all you do!
On 03.11.2025 21:10, bart wrote:
char data[] = {
<block of text from above>
};
Now, you're saying I ought to know what goes inside '[]'.
Well, yes. It's obviously 12 columns and 17 rows, as can quickly be
seen. - Of course I would expect that you know what sort of data the
program will generate, but if not, 12*17 = 170+34 = 204. If you have difficulties with simplest math - I think we've learned such things
when being 8 or 9 years old - and if you need more than five seconds
for that just pick from the simple language feature suggestions above instead.
The largest set of data I've included this way I think was 100M numbers.
That was testing embedding. But I have included actual binary data (eg.
images and executables) like this too.
I think hard-coding 10^8 numbers is not the wisest implementation,
to say the least, but without knowing the details I won't discuss
that; so let's just accept that the math (counting) is impractical
and one of the other two options will be applied to store the data
in-memory when using Algol 68.
But would you really inline such amounts of data? - Or did you mean
to read them in from external media?
initializer lists. - Whatever might apply for you, it doesn't seem
to be a clever approach.
BTW, as said, I most probably wouldn't store these amounts of data
in-memory, but I'd also have some doubts whether a language like
Algol 68, and specifically the Genie interpreter could handle that
amount of data in the first place; after all the "Genie" appears
to me to not have been trimmed to a low data space-consumption.
And a quick test confirms that: "a68g: abend: not enough memory."
So you'd have to use more intelligent solutions to process huge
amounts of data with Genie.
Or switch to other languages; I'm sure
"C" does not have that issue since you're there operating on the
lowest level.)
On 03/11/2025 20:10, bart wrote:
[...]> Maybe I will regenerate that data (perhaps it will be included
from some
file that I don't even look at) then I'd have to update the number.
It just shouldn't be necessary.
It isn't [in A68]. Use an identity declaration. Or a flexible array,
as Janis suggested.
Those decades of real-life experience (whatever your opinions about
that),
opened my eyes more to its practicial deficiencies.
(a) A68 is a language that is over 50 years old. It belongs to the era of mainframes, with jobs fed to them by physically taking decks of
cards
to a computing centre. The miracle is that it is still usable in the modern
environment.
(b) What you call "deficiencies" are almost always simply
cases
that your private languages do differently. But languages are not properly defined by merely giving examples; you also need to give the syntax, in sufficient detail that readers can determine whether their own code
conforms
to that syntax. Likewise the semantics. What is /your/ proposed syntax for
variable declarations? Then we can compare that with what A68 does, and see
what the trade-offs are.
It's clearly a language that
belongs more in academia.
Yet the first implementations were from RRE [defence establishment!] and it was, to my personal knowledge, used in engineering, natural language translation, data processing, accountancy, train routing, forestry, and
many
other areas of [1970s] computing, as well as many aspects of CS and maths.
I don't know what causes you to think it an "academic" language --
from the unfortunate fact that the first few textbooks on A68 were very
bad,
and impractical for proper teaching. [Both Pascal and C fared much
better in
this regard.]
I've finally noticed that that thread has gone very quiet after I showed that the main cause of the slowdown was cruft in the build script. The slowness was a symptom, but 'make -j' hid the symptom and left the underlying cause.
On 03/11/2025 21:31, Janis Papanagnou wrote:
On 03.11.2025 21:10, bart wrote:
char data[] = {
<block of text from above>
};
Now, you're saying I ought to know what goes inside '[]'.
Well, yes. It's obviously 12 columns and 17 rows, as can quickly be
seen. - Of course I would expect that you know what sort of data the
program will generate, but if not, 12*17 = 170+34 = 204. If you have
difficulties with simplest math - I think we've learned such things
when being 8 or 9 years old - and if you need more than five seconds
for that just pick from the simple language feature suggestions above
instead.
This is simply wrong. If a language (not A68, but using its syntax)
REQUIRES you to write this:
[n]INT a = (x1, x2, x3, .... xn)
That is, the 'n' has to exactly match the count of items, then that is
very poor.
There are several issues
- Finding out what N is in the first place
- Having to keep N in sync with the number of items, as things change
during development
- Having to either hardcode a literal for N, which is usually a no-no,
or needing to think up a name for it and define it separately
You seem to be dismissing that first one. Even if it is trivial to work
out, why do you need to bother? It is much better to just allow [] and
then it doesn't matter what the count is.
My data could have been all on one line. It could been read from an
external file. That could have been generated from a process which is
part of a build-script (LD'O's suggestion), then you will not know what
it will be before you start to build.
There some instances where you do need a count (for example it has to
match something else in the program) so you can /optionally/ supply it,
and the compiler can report a mismatch if the item count is wrong.
Otherwise, things can get very tedious if you have to get ? exactly
right here:
char message[?] = "<some long string literal>";
Some have better things to do!
On 04/11/2025 12:10, bart wrote:
I've finally noticed that that thread has gone very quiet after I
showed that the main cause of the slowdown was cruft in the build
script. The slowness was a symptom, but 'make -j' hid the symptom and
left the underlying cause.
Just to be clear here - threads like that on comp.lang.c tend to go
quite because people have got fed up repeating the same things, offering advice and help that is ignored, asking questions that are left
unanswered, and seeing nothing but off-topic navel-gazing claims about
how wonderful your personal languages are. (Your languages are topical here in comp.lang.misc, and I have nothing against discussing them here,
but they are very much off-topic in c.l.c.)
When you post something new, I think it is reasonable to expect more responses.
On 04/11/2025 12:10, bart wrote:
I've finally noticed that that thread has gone very quiet after I
showed that the main cause of the slowdown was cruft in the build
script. The slowness was a symptom, but 'make -j' hid the symptom and
left the underlying cause.
Just to be clear here - threads like that on comp.lang.c tend to go
quite because people have got fed up repeating the same things, offering advice and help that is ignored, asking questions that are left
unanswered, and seeing nothing but off-topic navel-gazing claims about
how wonderful your personal languages are. (Your languages are topical
here in comp.lang.misc, and I have nothing against discussing them here,
but they are very much off-topic in c.l.c.)
When you post something new, I think it is reasonable to expect more responses.
On 04.11.2025 16:46, David Brown wrote:
On 04/11/2025 12:10, bart wrote:
I've finally noticed that that thread has gone very quiet after I
showed that the main cause of the slowdown was cruft in the build
script. The slowness was a symptom, but 'make -j' hid the symptom and
left the underlying cause.
Just to be clear here - threads like that on comp.lang.c tend to go
quite because people have got fed up repeating the same things, offering
advice and help that is ignored, asking questions that are left
unanswered, and seeing nothing but off-topic navel-gazing claims about
how wonderful your personal languages are. (Your languages are topical
here in comp.lang.misc, and I have nothing against discussing them here,
but they are very much off-topic in c.l.c.)
Well said.
Indeed I read your post, while having completely ignored (not read)
bart's reply; at some point when all is said - sometimes, depending
on the poster, when all has been said even multiple times - it's not
worth to waste more time. (Maybe I'll come back later to the unread
posts, but they might then have already expired.)
The only drawback is that he might think non-responding means that
he's right - but that's meaningless; attentive readers will judge
themselves which facts they find worthwhile and right, and what not.
Just one point; while it is (as you said) indeed topical here I'd
not be happy if he'll expose the same pathological behavior here
that he's shown for ages in c.l.c (those things you listed above).
Janis
When you post something new, I think it is reasonable to expect more
responses.
[...] Here in c.l.misc, his languages are as much on-topic as Algol 68,
and I don't see a problem with comparisons.
[...] All I can say is that it is best to
respond to the content of posts when you have something useful to say,
and try not to respond too much to the person - [...]
On the whole, while Bart regularly misunderstands C and fails to learn
from others, and seems to be in a class of his own when it comes to have trouble with regular programming or software build tasks, his posts
often spur interesting discussions, and there is often agreement in some
of the things he says.
On 04/11/2025 17:26, Janis Papanagnou wrote:
If the discussion is not leading to anything
interesting (after all, details of a private language are not directly relevant to anyone else
from others, and seems to be in a class of his own when it comes to have trouble with regular programming or software build tasks,
On 04.11.2025 17:49, David Brown wrote:
[...] Here in c.l.misc, his languages are as much on-topic as Algol 68,
Sure.
and I don't see a problem with comparisons.
There's many problems if you try to compare well known (specified)
languages with home-brewed languages. All we typically see then is
examples of local specific details, thereby completely missing the
whole picture. It makes no sense to compare with such languages on
that level. (YMMV.)
[...] All I can say is that it is best to
respond to the content of posts when you have something useful to say,
and try not to respond too much to the person - [...]
Yes, and this is often, as in this specific personal case, hard to
achieve...
On the whole, while Bart regularly misunderstands C and fails to learn
from others, and seems to be in a class of his own when it comes to have
trouble with regular programming or software build tasks, his posts
often spur interesting discussions, and there is often agreement in some
of the things he says.
...as we see.
Janis
On 04/11/2025 17:38, Janis Papanagnou wrote:
On 04.11.2025 17:49, David Brown wrote:
[...] Here in c.l.misc, his languages are as much on-topic as Algol 68,
Sure.
and I don't see a problem with comparisons.
There's many problems if you try to compare well known (specified)
languages with home-brewed languages. All we typically see then is
examples of local specific details, thereby completely missing the
whole picture. It makes no sense to compare with such languages on
that level. (YMMV.)
That would be an interesting discussion, as to why you think the
provenance or history of a language, and of its implementation, somehow invalidates comparisons of their features, performance, and general
utility.
On 04/11/2025 16:49, David Brown wrote:
On 04/11/2025 17:26, Janis Papanagnou wrote:
If the discussion is not leading to anything interesting (after all,
details of a private language are not directly relevant to anyone else
Why not? People can talk about hypothetical language features, can't they?
Then what does it matter if they happen to be part of an actual, working language?
I for one would give more weight to a feature that had been proven in
the field by being part of a working implementation.
I will also mention when a feature works poorly or has been dropped.
from others, and seems to be in a class of his own when it comes to
have trouble with regular programming or software build tasks,
Yes. I haven't been brainwashed by Unix, and only encountered C very
late. So I have loads of experience of using quite viable alternatives.
All I can say about the former is that it is better than Windows at
building software designed to be built on Unix, which is no surprise.
On 03/11/2025 21:31, Janis Papanagnou wrote:
On 03.11.2025 21:10, bart wrote:
char data[] = {
<block of text from above>
};
Now, you're saying I ought to know what goes inside '[]'.
Well, yes. It's obviously 12 columns and 17 rows, as can quickly be
seen. - Of course I would expect that you know what sort of data the
program will generate, but if not, 12*17 = 170+34 = 204. If you have
difficulties with simplest math - I think we've learned such things
when being 8 or 9 years old - and if you need more than five seconds
for that just pick from the simple language feature suggestions above
instead.
This is simply wrong. If a language (not A68, but using its syntax)
REQUIRES you to write this:
[n]INT a = (x1, x2, x3, .... xn)
That is, the 'n' has to exactly match the count of items, then that is
very poor. There are several issues
- Finding out what N is in the first place
- Having to keep N in sync with the number of items, as things change
during development
- Having to either hardcode a literal for N, which is usually a no-no,
or needing to think up a name for it and define it separately
You seem to be dismissing that first one. Even if it is trivial to work
out, why do you need to bother?
It is much better to just allow [] and
then it doesn't matter what the count is.
My data could have been all on one line.
It could been read from an external file.
That could have been generated from a process which is
part of a build-script (LD'O's suggestion), then you will not know what
it will be before you start to build.
There some instances where you do need a count (for example it has to
match something else in the program) so you can /optionally/ supply it,
and the compiler can report a mismatch if the item count is wrong.
Otherwise, things can get very tedious if you have to get ? exactly
right here:
char message[?] = "<some long string literal>";
Some have better things to do!
The largest set of data I've included this way I think was 100M numbers. >>> That was testing embedding. But I have included actual binary data (eg.
images and executables) like this too.
I think hard-coding 10^8 numbers is not the wisest implementation,
to say the least, but without knowing the details I won't discuss
that; so let's just accept that the math (counting) is impractical
and one of the other two options will be applied to store the data
in-memory when using Algol 68.
But would you really inline such amounts of data? - Or did you mean
to read them in from external media?
I mentioned embedding binary data, in cases where the language doesn't
have such a feature built-in. There are utilities that can convert a
file into a data-block suitable for a language such as C. Eg. my example
will work in any language that accepts hex literals, or it could simple
have used decimal.
[...]
Most scripting languages can deal with strings, and those can be large,
eg. Python:
a = "A" * 100_000_000
print (len(a+a)) # 200000000
I assume they can include binary data including embedded zeros.
If A68G can't do that, then it's a QoI issue.
On 04/11/2025 17:38, Janis Papanagnou wrote:
On 04.11.2025 17:49, David Brown wrote:
[...] Here in c.l.misc, his languages are as much on-topic as Algol 68,
Sure.
and I don't see a problem with comparisons.
There's many problems if you try to compare well known (specified)
languages with home-brewed languages. All we typically see then is
examples of local specific details, thereby completely missing the
whole picture. It makes no sense to compare with such languages on
that level. (YMMV.)
That would be an interesting discussion, as to why you think the
provenance or history of a language, and of its implementation, somehow invalidates comparisons of their features, performance, and general
utility.
I'd also be interested in how much your views would be driven by
personal animosity.
(I'm also still waiting on that 'whole picture' thing.)
[...]
[...]
Use the appropriate flexible data structures to store various amounts
of data in arrays (in Algol 68)
REF [0:-1] INT a := (x1, x2, x3, ...)
[...]
On 04.11.2025 20:30, bart wrote:
On 04/11/2025 17:38, Janis Papanagnou wrote:
On 04.11.2025 17:49, David Brown wrote:
Sure.
[...] Here in c.l.misc, his languages are as much on-topic as Algol 68, >>>
and I don't see a problem with comparisons.
There's many problems if you try to compare well known (specified)
languages with home-brewed languages. All we typically see then is
examples of local specific details, thereby completely missing the
whole picture. It makes no sense to compare with such languages on
that level. (YMMV.)
That would be an interesting discussion, as to why you think the
provenance or history of a language, and of its implementation, somehow
invalidates comparisons of their features, performance, and general
utility.
To compare languages we need to have a substantial representation
of the compared languages. This is easy for known languages,
this
is pointless for, e.g., irrelevant home-brewed languages;
on a
feature-basis alone a _language comparison_ makes no sense and a
feature comparison makes little sense with this type of languages.
Someone else already observed and rightly pointed out that mostSome yes, but also they are what worked best. (Eg. my current module
of your objections are obviously merely your personal preferences.
After the many posts I'd have to add that it's also deliberate or intellectual ignorance
I'd also be interested in how much your views would be driven by
personal animosity.
My views are generally just based on my experience and knowledges
_on the topics_.
I'm generally trying to honestly explain - also to you - what you
are (often obviously)
just missing. I even repeat the facts that
you ignore. (Any "personal animosity" you may feel might likely
stem from you ignoring of what's explained and demonstrated often
multiple times to you. - My patience is not unlimited.)
(I'm also still waiting on that 'whole picture' thing.)
It's already been said:
Given all the discussions that people had with you of over the past
years, and your obvious inability
to see it (or understand it when
hinted), there's no point in wasting time repeating or summarizing
all that for you. - Good luck with all you do!
On 04.11.2025 13:24, bart wrote:
This is simply wrong. If a language (not A68, but using its syntax)
REQUIRES you to write this:
[n]INT a = (x1, x2, x3, .... xn)
That is, the 'n' has to exactly match the count of items, then that is
very poor. There are several issues
Then just don't write it (that 'n') (in Algol 68)
[] INT a = (x1, x2, x3, ..., xn)
It could been read from an external file.
Then you would not have the static initializer-lists that were part
of all examples you depicted. (You seem to be switching goalposts.)
That could have been generated from a process which is
part of a build-script (LD'O's suggestion), then you will not know what
it will be before you start to build.
Yes. - And I'm thinking about what I'd do, say, in "C" (or Algol 68).
Since we have no flexible and dynamically extensible constructs here
we need some more clever approach. If data comes from outside context
you need means to provide that information; the generator might count
and provide the information with the data he generates, or, if not,
an additional preprocessing (like wc -w) could be inserted to provide
the necessary information, or read in the data (as it comes, as text)
into a string and have the application count the semantic elements
before they get stored in the typed array.
How would you, in "C" (or Algol 68), get information of dynamic size
read into static structures? - realloc() on each element? realloc()
on chunks of data? Fixed size arrays of abnormal length 'int a[10^8]'
(that may still fail in yet more pathological cases)?
There some instances where you do need a count (for example it has to
match something else in the program) so you can /optionally/ supply it,
and the compiler can report a mismatch if the item count is wrong.
Otherwise, things can get very tedious if you have to get ? exactly
right here:
char message[?] = "<some long string literal>";
In Algol 68, here as well, there's no need to provide the length
[] CHAR message = "<some long string literal>"
Most scripting languages can deal with strings, and those can be large,
eg. Python:
a = "A" * 100_000_000
print (len(a+a)) # 200000000
I assume they can include binary data including embedded zeros.
If A68G can't do that, then it's a QoI issue.
Have you tried? - You can do, similar to the syntax above (in Algol 68)
STRING s = "A" * 1 000 000;
print (UPB (s+s))
As I've mentioned before (in another post) you may not expect arbitrary
sizes with the Genie interpreter. (A size of 10^8 wasn't possible in my standard configuration/setting.) But functionally it's possible.
But your example leaves me (yet again) with the impression that you are
just desperately seeking some detail, some feature, that Algol 68 does
not support, just to make the point that Algol 68 would be inferior to
this or that language. With a bit open-mindedness you can easily see - despite Algol 68 being an almost dead dinosaur - how clever its design
and how powerful its features are, how readable the code and reliable.
I'd have liked to see such sophistication in many of the later designed languages (that partly were, to my honest astonishment, often so badly timbered).
On 04/11/2025 00:35, I wrote:
I don't know what causes you to think it an "academic" language --The nature of the RR suggests that very strongly. It also does give
the impression that the language is perfect! Since it is so
meticulously designed, the slightest change would break it.
Another aspect, with A68G at least, is that there are lots of cryptic
error messages which uses nomenclature from the Report. For example: > a68: syntax error: 1: construct beginning with a serial-clause starting
in line 1 followed by "." and> then a formula, an enquiry-clause starting in line 2 is not a valid
serial-clause.
On 04/11/2025 20:30, bart wrote:
That would be an interesting discussion, as to why you think the
provenance or history of a language, and of its implementation,
somehow invalidates comparisons of their features, performance, and
general utility.
One aspect of this that I see (I can't speak for Janis, of course) is
that widespread languages have to handle a wide range of users and use- cases. Personalised languages are only used by one person, and for a
small range of tasks.
So you can easily be blinded by thinking only in
terms of what /you/ would write in your language, not what other people might write.
For example, I could say that C's type syntax is clear and obvious -
because whenever I write C code, the type syntax /is/ clear and obvious.
But that would be ignoring the possibility that someone else would
write "* * int (*)(int (*int)" as a type. For /your/ language, you /
can/ ignore the possibility that someone will write something horrible, because you are the only one writing in it, and you don't write horrible code (I assume!). Comparisons are thus between the best of your
language, and the worst of other languages (whether it be C, Algol, or anything else).
Then there is the "battle-tested" aspect. While I realise you wrote real-world code in your languages, they are not "battle-tested" in the manner of widespread languages - again, because you are "nice" to your language and tools.
We can see this in particular when modifying the language. If you want
to add support for 24-bit integers, you can hack on a "tribyte" keyword
and type fairly quickly by adding it to the source code of your
compiler.
In a mainstream language, such a change needs serious
consideration about how it fits with the language, any conflicts with existing code
(that could be millions of files), conflicts or
ambiguities with existing language constructs and syntax, how it could
work on multiple different types of target with different sized words,
On 04/11/2025 14:57, bart wrote:
Another aspect, with A68G at least, is that there are lots of cryptic
error messages which uses nomenclature from the Report. For example: >
a68: syntax error: 1: construct beginning with a serial-clause starting
in line 1 followed by "." and> then a formula, an enquiry-clause
starting in line 2 is not a valid
serial-clause.
The important bit there is "syntax error".
By definition, that
means that the compiler has been unable to parse what you wrote. The
rest is an attempt to tell you what the compiler has found. I find it
hard to imagine that you can read any textbook on Algol 68 that doesn't explain "serial clause" [etc]. It would be a lot more cryptic if it did
not use the standard terms [or "nomenclature" if you insist].
On 05/11/2025 23:59, Andy Walker wrote:
By definition, that
means that the compiler has been unable to parse what you wrote. The
rest is an attempt to tell you what the compiler has found. I find it
hard to imagine that you can read any textbook on Algol 68 that doesn't
explain "serial clause" [etc]. It would be a lot more cryptic if it did
not use the standard terms [or "nomenclature" if you insist].
Sorry, but the error messages really are poor. If I call a function
taking one argument, but I forget to provide it, then it says:
a68: error: 1: PROC (INT) INT cannot be coerced to [] "SIMPLOUT" in a strong-argument (detected in particular-program).
How about: 'missing argument' or something along those lines; would that really be more cryptic?
On 05/11/2025 11:25, Janis Papanagnou wrote:
On 04.11.2025 13:24, bart wrote:
This is simply wrong. If a language (not A68, but using its syntax)
REQUIRES you to write this:
[n]INT a = (x1, x2, x3, .... xn)
That is, the 'n' has to exactly match the count of items, then that is
very poor. There are several issues
Then just don't write it (that 'n') (in Algol 68)
[] INT a = (x1, x2, x3, ..., xn)
You seem to have missed a couple of things:
(1) This is not about Algol68
(2) This is specifically where a language needs those bounds up-front
Becase you stated there you saw no problem in discovering and having to include those bounds.
Since I've given some examples of where that would be awkward or
impossible, and haven't convinced you, I won't bother any further.
It could been read from an external file.
Then you would not have the static initializer-lists that were part
of all examples you depicted. (You seem to be switching goalposts.)
That could have been generated from a process which is
part of a build-script (LD'O's suggestion), then you will not know what
it will be before you start to build.
Yes. - And I'm thinking about what I'd do, say, in "C" (or Algol 68).
Since we have no flexible and dynamically extensible constructs here
we need some more clever approach. If data comes from outside context
you need means to provide that information; the generator might count
and provide the information with the data he generates, or, if not,
an additional preprocessing (like wc -w) could be inserted to provide
the necessary information, or read in the data (as it comes, as text)
into a string and have the application count the semantic elements
before they get stored in the typed array.
How would you, in "C" (or Algol 68), get information of dynamic size
read into static structures? - realloc() on each element? realloc()
on chunks of data? Fixed size arrays of abnormal length 'int a[10^8]'
(that may still fail in yet more pathological cases)?
I don't understand what you're saying. An example in C might look like
this:
char data[] = {
#include "file1" // both contain comma-delimited sequences
#include "file2"
};
This would be static data object. It is vastly more convenient to have
those bounds unspecified.
I expect we're talking at cross-purposes.
There some instances where you do need a count (for example it has to
match something else in the program) so you can /optionally/ supply it,
and the compiler can report a mismatch if the item count is wrong.
Otherwise, things can get very tedious if you have to get ? exactly
right here:
char message[?] = "<some long string literal>";
In Algol 68, here as well, there's no need to provide the length
[] CHAR message = "<some long string literal>"
So, why wouldn't you put the length here anyway?
You keep saying it's no
problem at all as you always know the length!
Or maybe in this case it /is/ a little too much work (Unicode plus
character encoding make the length ambiguous anyway).
But your example leaves me (yet again) with the impression that you are
just desperately seeking some detail, some feature, that Algol 68 does
not support, just to make the point that Algol 68 would be inferior to
this or that language. With a bit open-mindedness you can easily see -
despite Algol 68 being an almost dead dinosaur - how clever its design
and how powerful its features are, how readable the code and reliable.
It is disappointing, that a language that blew my mind when I first encountered it (remember I'd mostly used Fortran!) is now revealed to be
so lacking.
It is ten times as complicated as it needs to be for use for everyday
tasks.
It has lots of semi-esoteric features, of doubtful utility, but
which likely affect its general usefulness.
And it looks dreadful with most stropping schemes. Quite unlike all
those nicely typeset examples!
I'd have liked to see such sophistication in many of the later designed
languages (that partly were, to my honest astonishment, often so badly
timbered).
Clearly its aesthetics appeal to you (and maybe the fact that few
ordinary people can understand the programs you can write in it).
I would found it useless for the stuff I do (eg. implementing very fast interpreters that need to use unsafe, underhand methods), even if there
was a properly compiled version available.
(I believe there was an Algol68 front end for gcc released earlier this
year; I haven't looked at it. See https://gcc.gnu.org/wiki/Algol68FrontEnd)
On 06.11.2025 02:03, bart wrote:
On 05/11/2025 23:59, Andy Walker wrote:
By definition, that
means that the compiler has been unable to parse what you wrote. The
rest is an attempt to tell you what the compiler has found. I find it
hard to imagine that you can read any textbook on Algol 68 that doesn't
explain "serial clause" [etc]. It would be a lot more cryptic if it did >>> not use the standard terms [or "nomenclature" if you insist].
Sorry, but the error messages really are poor. If I call a function
taking one argument, but I forget to provide it, then it says:
a68: error: 1: PROC (INT) INT cannot be coerced to [] "SIMPLOUT" in a
strong-argument (detected in particular-program).
How about: 'missing argument' or something along those lines; would that
really be more cryptic?
Standalone 'missing argument' is to me clearer, but the presented error message seems to me to express something completely different than that,
so I suppose you cannot compare it. (But without seeing the actual code sample in this post it's pointless to speculate.
On 05.11.2025 15:28, bart wrote:
It is ten times as complicated as it needs to be for use for everyday
tasks.
It's one of the most coherent languages I've seen over the past
decades. It has an orthogonal design. That and other things makes
it _easy_ to understand and use, *not* complex.
Supported by the "problems" you report here and obviously have with
Algol 68 I can just guess that the problem is not the language here.
It has lots of semi-esoteric features, of doubtful utility, but
which likely affect its general usefulness.
(Bla, bla. - Nonsense.)
And it looks dreadful with most stropping schemes. Quite unlike all
those nicely typeset examples!
You said before that you don't like stropping in principle. This
just reinforces what someone here said before, that "most of your
objections are merely your preferences".
I'd have liked to see such sophistication in many of the later designed
languages (that partly were, to my honest astonishment, often so badly
timbered).
Clearly its aesthetics appeal to you (and maybe the fact that few
ordinary people can understand the programs you can write in it).
All the students back in my university days had not problem at all
learning Algol 68 en passant and programming with it. In our domain
we're all "ordinary people". The problem here is that your personal
mental reluctance to learn and understand concepts beyond your own preferences seems to be a severe hindrance.
I would found it useless for the stuff I do (eg. implementing very fast
interpreters that need to use unsafe, underhand methods), even if there
was a properly compiled version available.
Fair enough. (I don't think anyone would object to that.)
(I believe there was an Algol68 front end for gcc released earlier this
year; I haven't looked at it. See https://gcc.gnu.org/wiki/Algol68FrontEnd)
I've already heard about it but I have no need for another Algol 68
system, since I'm anyway using it only recreationally. But thanks.
Maybe others are interested (but I doubt it; who cares about a dead language).
Janis
On 06/11/2025 07:29, Janis Papanagnou wrote:
The concepts here are not as advanced or polished as they are in a
language like Haskell. It looks likes a regular imperative language but
it has that intimidatingly complex RR behind it.
I'm not surprised that Wirth got fed up with it and left the project to develop Pascal. That language really did have some innovative features.
On 06/11/2025 07:29, Janis Papanagnou wrote:
On 05.11.2025 15:28, bart wrote:
It is ten times as complicated as it needs to be for use for everyday
tasks.
It's one of the most coherent languages I've seen over the past
decades. It has an orthogonal design. That and other things makes
it _easy_ to understand and use, *not* complex.
You really can't see it? Read through that Revised Report, which has invented its own language for describing Algol68, and try and tell me
how that isn't completely over the top.
As for being orthognal, look at this set of function calls:
f(a, b); # 2 args
f(a); # 1 arg
f; # 0 args
Notice no parentheses on the last. Same goes for the declarations in
each case.
Or this:
INT a, b, c;
BITS x, y z;
a := b + c;
x := y XOR c;
Those last two lines are fine, but these are not:
a := b XOR c;
x := y + z;
a := y + c;
Or this:
BEGIN
a := 1;
b := 2;
c := 3
END
Each line ends with a semicolon - except the last in a block. Yes I understand the rule, but it means that because the last line is a
special case, you spend a lot of time dealing with it.
You can't temporarily comment out the last line, or temporarily add a
new last line, or move it elsewhere, or do any of usual stuff that comes
up in development, without reworking those semicolons.
And it looks dreadful with most stropping schemes. Quite unlike all
those nicely typeset examples!
You said before that you don't like stropping in principle. This
just reinforces what someone here said before, that "most of your
objections are merely your preferences".
Nobody likes stropping otherwise many more languages would look like Algol68. They decided that spaces within identifiers, the main
advantage, are just not worth the trouble.
I actually sometimes use stropping within my own projects, but it will either be for machine-generated content, or only rarely in user-code:
`exit()
This calls C's exit() function. Without the backtick, 'exit' is a
reserved word in my syntax.
I've just noticed another peculiarity of Algol68 (may be specific to A68G):
* Spaces are allowed in indentifiers, but they are not significant,
so that 'ab c' and 'a b c' are the same name.
* Identifiers must be lower case (I'd always thought it was case-
insensitive)
* Spaces are also ignored here: INTabc;
* But here: 'LONG INTabc def;'; 'LONG INT' are two tokens, but 'abc def'
are one token.
How can something so straightforward get so complicated!
The important bit there is "syntax error".I just pick up on 'error'! Then I have to try a different combination
of tokens until works.
[...] If I call a function taking one argument, but I forget to provide
it, then it says:
a68: error: 1: PROC (INT) INT cannot be coerced to [] "SIMPLOUT" in
a strong-argument (detected in particular-program).
How about: 'missing argument' or something along those lines; would
that really be more cryptic?
On 06/11/2025 01:03, bart wrote:
[I wrote:]
The important bit there is "syntax error".I just pick up on 'error'! Then I have to try a different combination
of tokens until works.
Somehow, I'm not surprised. Anything rather than learn the
syntax and semantics of the language you're using.
[...] If I call a function taking one argument, but I forget to provide
it, then it says:
a68: error: 1: PROC (INT) INT cannot be coerced to [] "SIMPLOUT" in
a strong-argument (detected in particular-program).
How about: 'missing argument' or something along those lines; would
that really be more cryptic?
It wouldn't be more cryptic, but as there isn't necessarily a missing argument it would be wrong. I could supply a more accurate
error message, but as you stop reading at "error" there's no point.
[Note that in A68G, to use your own example from a later article,
"fred()" is not directly an error.]
On 06/11/2025 15:18, bart wrote:
On 06/11/2025 07:29, Janis Papanagnou wrote:
On 05.11.2025 15:28, bart wrote:
It is ten times as complicated as it needs to be for use for everyday
tasks.
It's one of the most coherent languages I've seen over the past
decades. It has an orthogonal design. That and other things makes
it _easy_ to understand and use, *not* complex.
You really can't see it? Read through that Revised Report, which has
invented its own language for describing Algol68, and try and tell me
how that isn't completely over the top.
As for being orthognal, look at this set of function calls:
f(a, b); # 2 args
f(a); # 1 arg
f; # 0 args
Notice no parentheses on the last. Same goes for the declarations in
each case.
Or this:
INT a, b, c;
BITS x, y z;
a := b + c;
x := y XOR c;
Those last two lines are fine, but these are not:
a := b XOR c;
x := y + z;
a := y + c;
I don't know Algol, but if it distinguishes between types that can have bitwise logic operations and types that have arithmetic operations, then
I approve of that. These are separate concepts, and should use
different types. (IMHO, of course.)
Or this:
BEGIN
a := 1;
b := 2;
c := 3
END
Each line ends with a semicolon - except the last in a block.
Yes I understand the rule,
but it means that because the last line is a special case,
you spend a lot of time dealing with it.
I can see that being a nuisance. It's fine to say semicolons are
statement separators, but it would then be convenient if an empty
statement is allowed.
You can't temporarily comment out the last line, or temporarily add a
new last line, or move it elsewhere, or do any of usual stuff that
comes up in development, without reworking those semicolons.
And it looks dreadful with most stropping schemes. Quite unlike all
those nicely typeset examples!
You said before that you don't like stropping in principle. This
just reinforces what someone here said before, that "most of your
objections are merely your preferences".
Nobody likes stropping otherwise many more languages would look like
Algol68. They decided that spaces within identifiers, the main
advantage, are just not worth the trouble.
I agree with you here - stropping is not pleasant. It makes code harder
to read and harder to write.
It's better for a language to minimise the number of keywords it has
(or have some kind of "contextual keyword"
scheme, but these can get complicated),
and have namespaces so that you
don't crowd out the global or unqualified namespace.
[...]
I've just noticed another peculiarity of Algol68 (may be specific to
A68G):
* Spaces are allowed in indentifiers, but they are not significant,
so that 'ab c' and 'a b c' are the same name.
* Identifiers must be lower case (I'd always thought it was case-
insensitive)
* Spaces are also ignored here: INTabc;
* But here: 'LONG INTabc def;'; 'LONG INT' are two tokens, but 'abc def'
are one token.
I would love to see the bit in the language reference that explains
this point.)
On 06.11.2025 17:14, David Brown wrote:
* Identifiers must be lower case (I'd always thought it was case-
insensitive)
Reading a textbook helps. Here as well. (But I understand that; if
you'd spend the time to read you'd then have less time to post and
complain.)
On Thu, 6 Nov 2025 17:58:42 +0000, bart wrote:
I would love to see the bit in the language reference that explains
this point.)
Page 30 of the Revised Report:
N) PROCEDURE :: procedure PARAMETY yielding MOID.
O) PARAMETY :: with PARAMETERS ; EMPTY.
P) PARAMETERS :: PARAMETER ; PARAMETERS PARAMETER.
The docs are all public, you know ...
* But if declared with no parameter list, it has to be called as just F.
I wonder if anyone has ever thought of producing a 'cheatsheet' which summarises the essentials on one or two pages?
Here is that example:
PROC fred = (INT a)INT: 1234;
print(fred())
(BTW it takes a parameter because I couldn't figure out how to write an
empty parameter list.
[...] Anyway why wouldn't it be an error?
On 06/11/2025 17:58, bart wrote:
I wonder if anyone has ever thought of producing a 'cheatsheet' which
summarises the essentials on one or two pages?
Both the A68-R "User's Guide" and the Watt-Peck-Sintzoff one-page syntax chart have been referred to here within the past few weeks.
Here is that example:
PROC fred = (INT a)INT: 1234;
print(fred())
(BTW it takes a parameter because I couldn't figure out how to write an
empty parameter list.
You couldn't figure out that to write an empty list you write absolutely nothing, as in Algol 60, Pascal, ...?
[C was the first language
I used, several years after A68, where you had to provide the "()" even for
a parameterless procedure.]
I almost certainly tried that, and it probably gave errors for
other reasons. For example, this fails:> PROC main = VOID: print("hello");
main()
So then you try something else. [...]
But I'm just illustrating how someone can have trouble in figuringPROC f = VOID: whatever;
out the syntax of a parameterless function!
On 07/11/2025 14:34, Andy Walker wrote:
On 06/11/2025 17:58, bart wrote:
I wonder if anyone has ever thought of producing a 'cheatsheet' which
summarises the essentials on one or two pages?
Both the A68-R "User's Guide" and the Watt-Peck-Sintzoff one-page
syntax chart have been referred to here within the past few weeks.
Here is that example:
PROC fred = (INT a)INT: 1234;
print(fred())
(BTW it takes a parameter because I couldn't figure out how to write an
empty parameter list.
You couldn't figure out that to write an empty list you write
absolutely nothing, as in Algol 60, Pascal, ...?
I almost certainly tried that, and it probably gave errors for other
reasons.
For example, this fails:
PROC main = VOID: print("hello");
main()
with:
a68: syntax error: 1: VOID construct must yield a routine, row or structured value (detected in particular-program).
So then you try something else. I didn't know then that that main() was
at fault.
Yet, this works (or worked when I posted about what seemed to
be the rules for ()):
PROC main = ()VOID: print("hello");
main()
I tried it just now, and it doesn't work with either 'main' or 'main()':
a68: syntax error: 1: possibly a missing or erroneous symbol nearby.
a68: syntax error: 2: possibly a missing or erroneous separator nearby.
However yesterdays' test had a function that returned a value, like this:
PROC main = ()INT: (print("hello"); 0);
main()
Now, that works, and it works with 'main' or 'main()'. I've no idea why,
and at this point I don't care. This language's syntax seems incredibly
- you're on eggshells the whole time.
But I'm just illustrating how someone can have trouble in figuring out
the syntax of a parameterless function!
[...]
On 07.11.2025 16:42, bart wrote:Well, I now know exactly what YOU are.
Strangely, if I write this code, I get the message:
a68: syntax error: 1: You stupid moron this is not C, get an
Algol 68 textbook before trying to write Algol 68 programs!
On 07/11/2025 15:42, bart wrote:
I almost certainly tried that, and it probably gave errors for
other reasons. For example, this fails:> PROC main = VOID:
print("hello");
main()
Of course it does. "main" returns no value, yet you're
trying to subscript/parametrise/call that value.
So then you try something else. [...]
Or you look at the syntax rules instead of floundering
around trying random combinations of parentheses?
But I'm just illustrating how someone can have trouble in figuringPROC f = VOID: whatever;
out the syntax of a parameterless function!
PROC g = INT: whichever;
...
f;
print (g);
...
What could be simpler?
On 07/11/2025 16:50, Andy Walker wrote:
This is one of your examples, but with () added to it:
PROC g = ()INT: 1234;
print(g)
It still apparently works. So let's try this:
MODE IFUNC = PROC INT;
INT n:=0;
PROC g = INT: (n+:=1; 1234);
IFUNC x = g;
[... H]ere is a quote on the topic from https://cacm.acm.org/blogcacm/niklaus-wirth-or-the-importance-of-being-simple/ :> "Wirth recognized Algol 68 for what it was, a catastrophe."
" [... T]o make everything work with everything, you have to complicateSo unbelievable that it was impossible to write a compiler. Oh,
the compiler to unbelievable extremes, [...]."
The real catastrophe was nothing to do with Algol 68 as a language
but was the fact that, for fear of being mocked by Wirth and others,
newer languages never have a proper formal definition.
[...] Read through that Revised Report, which has invented its own language for describing Algol68, and try and tell me how that isn't completely over the top.
So what's happening here:
PROC main = ()INT: (print("hello"); 0);
main
PROC main = ()INT: (print("hello"); 0);main()
main returns 0 in both cases. Both work. [...]
Are these examples actually returning anonymous functions, [...].
So let's try this:
MODE IFUNC = PROC INT;
INT n:=0;
PROC g = INT: (n+:=1; 1234);
IFUNC x = g;
print(x);
print(x);
print(x);
print(n)
Output is:
+1234 +1234 +1234 +3
So, somebody can unwittingly create an anonymous function [...].
Back to Algol68, then given:
PROC f = (INT a)INT: ... # regular function with one param
PROC g = INT: ... # with zero params
PROC h = ()INT: ... # anonymous function with zero params
How do you express an anonymous function that takes parameters?PROC (INT a) INT: ...
On 07/11/2025 19:49, bart wrote:
So what's happening here:
PROC main = ()INT: (print("hello"); 0);
main
PROC main = ()INT: (print("hello"); 0);main()
You do realise that in both cases you are defining "main" to
return an array of integers?
main returns 0 in both cases. Both work. [...]
Because "0" has been coerced to an array of one integer.
Are these examples actually returning anonymous functions, [...].
No, of course not.
So let's try this: MODE IFUNC = PROC INT;
INT n:=0;
PROC g = INT: (n+:=1; 1234);
IFUNC x = g;
print(x);
print(x);
print(x);
print(n)
Output is:
+1234 +1234 +1234 +3
So, somebody can unwittingly create an anonymous function [...].
??? It's not anonymous -- you've carefully given "g" a second name, "x", via that identity declaration.
[...]
Back to Algol68, then given:
PROC f = (INT a)INT: ... # regular function with one param
PROC g = INT: ... # with zero params
PROC h = ()INT: ... # anonymous function with zero params
It isn't anonymous -- you've called it "h".
How do you express an anonymous function that takes parameters?
PROC (INT a) INT: ...
You seem to have a very weird mental picture of what A68 is!]
On Fri, 7 Nov 2025 21:22:39 +0000, Andy Walker wrote:
The real catastrophe was nothing to do with Algol 68 as a language
but was the fact that, for fear of being mocked by Wirth and others,
newer languages never have a proper formal definition.
I was doing dual undergrad Physics and Comp Sci majors when I came across the Algol 68 report. I read it, it blew my mind, but understanding
something of the limitations of BNF, I appreciated how it was such an advance.
Then I was quite incredulous to discover that many computer scientists rejected that formalism as unnecessary complex and too hard to understand, and kept on with the old-school simplistic formal notation plus lots of narrative explanation.
To me, it was as though physicists had rejected quantum theory as unnecessarily complex and too hard to understand, and insisted on trying
to describe the world as being based on Newtonian mechanics ...
On 06/11/2025 15:58, bart wrote:
[... H]ere is a quote on the topic from
https://cacm.acm.org/blogcacm/niklaus-wirth-or-the-importance-of-being-simple/ :> "Wirth recognized Algol 68 for what it was, a catastrophe."
The real catastrophe was nothing to do with Algol 68 as a language
but was the fact that, for fear of being mocked by Wirth and others, newer languages never have a proper formal definition.
To expand a bit, I looked at example van Wijngarden grammar that
specifies that indentifiers are defined befor use. Trouble is,
propery specified by this grammar is essentially trivial, but
the corresponding grammar is not trivial.
Van Wijngarden grammars are heavy and badly adapted to semantic
properties.
Andy Walker <[email protected]> wrote:
The real catastrophe was nothing to do with Algol 68 as a language
but was the fact that, for fear of being mocked by Wirth and others, newer >> languages never have a proper formal definition.
Algol 68 definition is hard to read and due to this almost useless.
Now we know better how to give formal definitions. Pascal standard
give precise and reasonably readible definition of the language
(even if is is not as formal as you wish). Scheme, SML and
Haskel claim to have formal definition of semantics, something
which IIUC Algol 68 did _not_ have.
[...]
On 06/11/2025 18:41, Janis Papanagnou wrote:
On 06.11.2025 17:14, David Brown wrote:
* Identifiers must be lower case (I'd always thought it was case-
insensitive)
Regarding the above point, I'd be delighted to be pointed to a reference that states it categorically.
But I suspect it depends on the stropping scheme used. For A68G, I had assumed that all-caps were reserved words, with mixed-case and lower
case being identifiers. But mixed-case can't work if "OneTwo" is four tokens.
On Sat, 8 Nov 2025 03:50:00 -0000 (UTC), Waldek Hebisch wrote:
To expand a bit, I looked at example van Wijngarden grammar that
specifies that indentifiers are defined befor use. Trouble is,
propery specified by this grammar is essentially trivial, but
the corresponding grammar is not trivial.
Not really, no. The formal grammar is able to specify the fact that an identifier does *not* need to be defined before use; it just needs to be defined *somewhere* that is accessible within the relevant scope. For example, two procedures can be mutually recursive; Algol-68 does not
require Pascal-style (or C-style) forward declarations.
The only thing that needs to be defined before use is the precedence of a custom operator -- this is to allow the compiler to parse the structure of expressions using that operator. The actual operator definition can be deferred to later.
And also, the syntax does not allow a struct to directly contain fields of its own type, while it *does* allow fields of type pointer to the struct.
The grammar notation is sophisticated enough to distinguish between the
two cases. Clever, eh?
The formal grammar is also able to specify the fact that all declarations
of identifiers in a block must occur before the first label in that block. This way, there is no need to deal with the question of what happens if a declaration is executed more than once within a block, because there is no way for a GOTO to go back to before any declarations within that block.
Van Wijngarden grammars are heavy and badly adapted to semantic
properties.
Do you consider the above properties to be “semantic” or “syntactic”?
On 08/11/2025 00:26, Andy Walker wrote:
[...]
PROC f = ()INT: (10,20,30,40);
[...]
But change f slightly:
PROC f = (INT a)INT: (10,20,30,40);
print(f(1))
And now it's very different. [...]
Look also the confusion below. I think, at some point, you have to admit
some liability in the language if someone with half a century's
experience has this much trouble understanding what the hell is going on.
I don't remember this much trouble in other languages I've dabbled in,
and with those I also work from existing examples or on-line queries or
from trial and error. I didn't have to study large references tomes to
get the info I needed.
This to me is a failing in the language design. It might all make
perfect sense to a compiler (and even those took some effort) but it has
to be intuitive to humans too.
Notice also that, despite the strictness, it gives a lot of freedom, so
that you type something wrong, but rather than report an error, it just silently enables some other behaviour that you are not aware of. It is fragile.
[...][...]
You seem to have a very weird mental picture of what A68 is!]
It's a lot, lot weirder than I remembered from 1980. [...]
On 08.11.2025 02:54, bart wrote:
This to me is a failing in the language design. It might all make
perfect sense to a compiler (and even those took some effort) but it has
to be intuitive to humans too.
It makes perfectly sense to programmers who learned the basics of the language (as thousands of people have done). Don't blame the language
for your ignorance and unwillingness to learn it before using it.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 78:38:35 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
5,986 files (1,957M bytes) |
| Messages: | 2,443,207 |