On 28/11/2021 12:52, Bart wrote:
> OK, you can understand that internally, a language+implementation can
> do things as it pleases, just so long as the user can do A+B and it
> does what is expected of it.
> Which means /my/ implementation can choose to handle it as it likes
> too.
Of course it can.
> Yet not long ago you seemed to keen to implement things like:
> A +:= B
> via operator-overload mechanisms expressed within the language
> itself.
??? You again fail to distinguish between how something
is defined, and how it is implemented. "A +:= B" is defined by
the RR, /together with/ [as in many language specifications] a
general rule [end of RR10.1] that the definition describes the
effect, and implementations are free to use more efficient
methods. In the instant case, the RR explains what "A +:= B"
is supposed to do; you can't really expect it to give the
machine code for your computer, that's up to the compiler.
> And more recently that you wanted new comparison operators to
> be defined the same way.
If you have a new operator, how would you propose it be
defined, in general, other than within the language? We can't
go around re-revising the language specification every time
someone thinks of a new useful operator, nor every time someone
invents new hardware with different machine code.
> In that latter case, the benefits of the language allowing such new
> features without bothering the language or changing the compiler,
> seemed to be outweighed by the poor quality and limitations of the
> result (and its non-stardardness!)
Two different things. As noted during the debate, I
personally have no requirement for "A < B < C"; I merely point
out that I can at least /define/ what that means within A68.
If I point out some useful operator that your language is
missing [eg, the ability to write "A + B" where "A" and "B"
are graphs or games or functions], you have to change your
compiler [and its associated documentation]; I just write
and annotate some more A68. "Poor quality" is a matter of
opinion; you're like the man who, seeing his neighbour's
dog playing chess, complained that it wasn't playing very
well. "Limitations" are your lack of imagination. "Non-
standardness" happens every time you write a new function
in your program; it is up to good programmers to give new
functions sufficiently descriptive names [or comments].
The same applies to operators and types.
> But it seems my approach is perfectly valid too.
Of course it is, if that's all you want. But it
doesn't work for standardised languages used by lots of
people, and perhaps across lots of hardware.
> I've just used gcc to build a 4-line hello.c program; it took over 5
> seconds even on my somewhat faster new PC, less than 1 line per
> second!
Perhaps you should switch to plain old "cc"? Oh,
wait, on my machine that is a symlink to "gcc". On my home
PC, thirteen years old and nothing fancy, it compiles and
runs a "hello.c" program in 0.04s, only 3x slower than A68G.
[...]
>>> Except that it isn't a matter of syntax; that's too constraining.
>> It /is/ a matter of syntax in the RR; in what sense is
>> it constraining? If you use undeclared variables, do you not
>> want the compiler to detect the error?
> But it's nothing to do with syntax!
In the RR, it /is/ to do with syntax. ...
> Syntax is just the shape of the
> code. Here is the kind of syntax we've been using:
> A + B
> That's a perfectly valid expression in most normal languages. Except
> in Algol68, because A and B haven't been declared?
... If there is no declaration for "A" and "B", then it
may be syntactically correct in your language, but it surely is
not valid? In A68, there is no route from the concept "program"
to "... letter a symbol, plus symbol. letter b symbol, ..." if
they are not declared. Whether the compiler reports that as a
syntax error or more helpfully as "identifier A not declared" is
a matter of QoI.
> It's far simpler to separate these different ideas: the shape of the
> code; the resolving of the names (which may detect they are
> undefined); the code generation, execution etc.
So much simpler that the C, C++, Ada, ... standards are
much bigger, much harder to navigate, and leave far too much
ill-defined. Of course, if your language doesn't /have/ a
standard, that is indeed much simpler. But as soon as C moved
away from the one implementation at Bell Labs, and it was no
longer possible for everyone to ask DMR what something meant,
it all became more complicated. /You/ grumble about the result
in practically every exchange here with DB.
Anyway, /you/ see them as "these different ideas". The
RR sees at least the first two as a unified whole; there is a
book, "Grammars for Programming Languages" by Cleaveland and
Uzgalis which explains how to integrate all the rest also into
one single grammar. You might think that's going too far?
> In my dynamic language, it doesn't care they might be undefined until
> runtime.
That's fine; it just means that your language is not
the same as C or Algol or ... in this respect. Leaving things
to runtime has its own pros and cons; you seem very unwilling
to accept that some issues are "on the one hand ..., on the
other ..." so that there is a balance to be struck -- which
sometimes comes down one side, sometimes the other.
> Instead, Algol68 chooses the most complex approach all, that is hard
> to understand and difficult to implement.
You aren't expected to learn A68 from the RR, but from
a suitable textbook. It's not hard to learn, unless you are
claiming that you are substantially more stupid than the many
thousands of students who learned A68 as their first language
in [mainly] the 1970s. It's certainly harder than Pascal to
implement; but you write compilers once and use them many
times, so the difficulty is amortised over thousands of uses.
>> Or do you prefer the
>> early versions of Fortran or C where the compiler assumes that
>> an undeclared "j" [for example] is an integer variable?
> If that's what the language said, then that's what it will be. If I
> execute this complete program of my 'Q' language:
> print j
> it says:
> <Void>
> (That's not an error, but most other uses are.)
In a compiled language, it's a disaster waiting to
happen, which is why it was dropped from Fortran and C.
Again, the balance of risk is different in different
environments. Serious [esp life-critical] code should not
depend on things that can easily happen by accident, eg by
a simple typo.
> It's not exactly the end of the world. In Algol68:
> INT j;
> print(j)
> gives a runtime error. So j might be defined, but it hasn't done much
> good! I guess the RR doesn't make correct /initialisation/ part of
> the syntax?
It's undefined by the RR, and in general is not
computable at compile time. Requiring initialisation along
with the declaration is inefficient [think eg of a large
array where the required values are derived, eg, from user
input, so that filling in zeroes, for example, would be
wasted]. A68G, as you have found, treats it as a run-time
error; yes, there's a speed penalty, but it also picks up
lots of programming errors.
> [...] What I can confidently say is that, to me,
> [the RR] is almost completely useless for any purpose.
That's fine. You're not writing an A68 compiler.
But it also means that you're equally almost completely
unqualified to comment on any matter of A68.
Composer of the day:
www.cuboid.me.uk/andy/Music/Composers/Ravel