On 01/11/2021 23:00, Andy Walker wrote:
> On 31/10/2021 10:52, Bart wrote:
> [I wrote, re Algol:]
>>> [...] Your program is embedded in an
>>> environment in which lots of things are defined for you, but you
>>> don't have to stick with the normal definitions. It will all be
>>> visible in your code, so it's up to you whether you choose to
>>> confuse yourself or not.
>> I don't buy that. You will confuse yourself, and anyone who tries to
>> read, understand, modify or port your program. And there will be
>> problems mixing code that has applied different semantics to the same
> With respect, that's just silly. You aren't forced to define
> or use your own operators; the standard ones are broadly the same as
> those in every other normal language. So are the priorities, and the
> standard functions. If a skilled programmer /chooses/ to provide
> some new operators [and aside from deliberate attempts to obfuscate
> for competition purposes, and such like], then it is to make code
Sorry, but I had a lot of trouble understanding your A68 example. For
example, part of it involved arrays, which I thought was some extra
ability you'd thrown in, but I think now may actually be necessary to
implement that feature. [I still don't know...]
It reminds me of posts in comp.lang.c where people claim some new
feature is not necessary. because it so 'straightforward' to
half-implement some terrible version of it via impenetrable
> For example, if you happen to be doing matrix algebra,
> it is likely to be much clearer if you write new operators rather
> than new functions, so that you can reproduce quite closely normal
> mathematical notations.
It could well be clearer, AFTER you've had to implement it via code that
is a lot less clearer than ordinary user-code.
(My first scripting language had application-specific types including 3D
transformation matrices and 3D points. There, if A and B are matrices,
and P is a point, then:
C := A*B # multiples matrices
Q := C*P # use C to transform P
/That/ was clear, with the bonus that the user didn't need to implement
a big chunk of the language themself!)
> Code will only be "mixed" if several
> people write different bits of a project /without/ agreeing the
> specifications of their own bits; that is a problem for /any/
> large project, and nothing to do with Algol. You can write code
> that is difficult to "read, understand, modify or port" in any
> non-trivial language; again, nothing special about Algol, more to
> do with unskilled programmers following dubious practices.
If the effect is to create lots of mini, overlapping dialects or
extensions, then that is a problem. There will be assorted custom
preludes or drag in too.
>> I do very little in the way of listing processing, but it's handling
>> mostly with user-functions, and I do not support chained comparisons.
>> However, they are in the standard library.
> If you don't "support" them then what do you mean by "in the
> standard library"?
They are implemented as user-functions which are placed in a library
that comes with the language.
>> Something like your '0 < int (a,b,c)' would be written as:
>> mapsv(('<'), 0, (a,b,c))
>> with a vector result.
> Is that supposed to be clearer?
I'm not pretending my language properly supports list operations. That
would be a very different kind of language.
My mapsv is clearer for me since the 's' and 'v' indicate that it takes
a 'scalar' and a 'vector' operand. ('scalar' here just means it is
treated as a single value, and 'vector' that it is a multiple value.)
Then the rules for that removes any confusion about the result:
mapsv(op, A, B): scalar op vector -> vector
> What are the specification
> for your "mapsv" function, and what am I supposed to do if I want
> something slightly different? [My Algol snippet was entirely user-
> written, and could easily be tweaked any way I chose, all there and
> visible in the code. If you want something different, take it and
> tweak it your own way -- entirely up to you.]
global function mapsv(op,as,b)=
#Apply op or function between elements of single value as and vector b
forall i,x in b do
(Hmm, maybe 's' stands for 'single' not 'vector'!)
mapss is an actual built-in function which is awkward in user-code,
since 'op' can be any built-in binary op, or any user-function taking
The language has poorly developed operator overloading which is little used.
I don't think you can write my mapss() function in Algol68. Example:
println mapss( (random(1..4)|(+), (-), (*)| (/)), a, b)
Output is 240.
>> Examples? I can't think of any Algol features in C, unless you're
>> talking about very early days.
> Early days were important for C, as when there was only K&R
> C, and C was "what DMR's compiler does", it was easy to change the
> language, and there are a fair number of changes between the first
> versions and 7th Edition Unix. More recently, they have added
> type "Bool", dynamic arrays, stronger typing, parallel processing,
> complex numbers, anonymous structures and unions, possible bounds
> checking, "long long" types and related ideas, mixed code and
> declarations, better string handling, and doubtless other things
> I've forgotten.
OK, but its implementations of those are crude and remain low level.
People mainly use them to write poorer code that is harder to follow.
> You can't fix "break" or "a*b"; by the time of 7th Edition,
> it was already too late,
It's never too late. An alternate to 'break' could have been introduced
for switch, eg. have both 'break' and 'breaksw'; eventually only
'breaksw' is allowed, and 'break' is an error. Then, further along,
'break' inside switch is allowed to be used for loop-break.
However, try taking a program from 1980 and try compiling it now.
Actually, take a program from 2021 and try building it with two
>> The grief would be in having to write:
>> IF a=b AND b=c AND c=d THEN
>> or, in devising those operator overloads, which still doesn't give
>> you a nice syntax, and will restrict the types it will work on,
>> instead of just writing:
>> if a=b=c=d then
> Allowing "a=b=c=d" shows that "a=b" means one thing if it
> is "stand alone" and something quite different if it is a left
> operand. You're very good at saying "my language allows XXX" for
> all manner of interesting and perhaps even desirable "XXX", but
> it's at the expense of specifying exactly what the related syntax
> and semantics are.
I copied the feature from Python. You'd need to ask Guido what it means!
> In Algol, expressions are parsed by the usual
> rules of precedence and [L->R] associativity, after which "a o b"
> for any operands "a" and "b" and any operator "o" means exactly
> the same as "f(a,b)" where "f" is a function with two parameters
> of the same types as those of "o" and the same code body as that
> of "o", all completely visible in the RR plus your own code.
> What's the corresponding rule in your language?
If I write:
A = B = C
in static code, then it works something like this:
* The dominant type of A, B, C is determined
* A, B, C are converted to that type as needed, as values A', B', C'
(This is for numeric types; "=" also works for exactly compatible
arbitrary types with no conversions applied)
* The expression returns True when A', B', C' have identical values