This is to follow up on comments from another thread. It's prompted by a
picture of a calculator which Bart posted:

https://upload.wikimedia.org/wikipedia/commons/9/9c/Hp35s_Calculator.jpg

I think the issue being discussed was what operators should be provided
by a language. I'd suggest almost none!

Don't get me wrong! AISI there should be standard operator /symbols/
such as +, *, >>, etc (and possibly some reserved operator words such as
"and" and "or") and they should have precedences and associativities but
that they should be semantically meaningless. Instead, they would be
given meaning by the data types to which they are applied.

That's not as strange as it may sound. In

A + B

the meaning of + will depend on whether A and B are ints or floats - or,
possibly, strings or some user-defined type.

If the meaning depends on the types of the operands then it doesn't have
to be built in but can be defined by code /for the requisite type/. For
example, if A and B are floats and there's a definition for the type
'float' which includes the following

type float
function "+"(float self, float other)
... code for float addition ...

then the code therein could carry out the necessary floating-point
addition. (I'm being deliberately vague about how as this topic is more
about invocation.)

The first point is that type float can be an external module and not
part of the language. The same is possibly true also of signed and
unsigned integers!?!

IOW the /language/ would define the precedences and associativity of
operator symbols or standard names but the meaning of those operators
would be defined /externally/.

The second point is that named prefix operations such as ABS and SIN -
and many like them - would not need to be part of the language. For one
thing, they could be defined in external modules and, for another, they
would appear best as functions rather than as operators. For example, in

abs(y)

the abs function referred to would depend on whether y was an int or a
float, and a call such as

sin(x)

would work for x being a float but the name "sin" would be undefined if
x were an integer.

Going back to the calculator, aside from common operations surely most
of the more obscure actions one could find on a calculator such as
statistical and financial operations would be most clearly expressed in
code by

op_name(args)

Further, that 'named prefix' form allows any number of functions to be
apply-able to the types of its args. Possibly most of an advanced
calculator's functions are unary, anyway, so the prefix form would be
more appropriate.

With function form there's no ambiguity about how any operations are
applied and the names give a clue as to the meaning. For example,

factorial(x)

gives a big clue as to what it might do....!

In sum, perhaps it would be better to build common operators into type
libraries and not make them part of the language itself.

--
James Harris

On 21/11/2021 18:55, James Harris wrote:
> This is to follow up on comments from another thread. It's prompted by a
> picture of a calculator which Bart posted:
>
> https://upload.wikimedia.org/wikipedia/commons/9/9c/Hp35s_Calculator.jpg
>
> I think the issue being discussed was what operators should be provided
> by a language. I'd suggest almost none!
>
> Don't get me wrong! AISI there should be standard operator /symbols/
> such as +, *, >>, etc (and possibly some reserved operator words such as
> "and" and "or") and they should have precedences and associativities but
> that they should be semantically meaningless. Instead, they would be
> given meaning by the data types to which they are applied.
>
> That's not as strange as it may sound. In
>
>   A + B
>
> the meaning of + will depend on whether A and B are ints or floats - or,
> possibly, strings or some user-defined type.
>
> If the meaning depends on the types of the operands then it doesn't have
> to be built in but can be defined by code /for the requisite type/. For
> example, if A and B are floats and there's a definition for the type
> 'float' which includes the following
>
>   type float
>     function "+"(float self, float other)
>       ... code for float addition ...
>
> then the code therein could carry out the necessary floating-point
> addition. (I'm being deliberately vague about how as this topic is more
> about invocation.)
>
> The first point is that type float can be an external module and not
> part of the language. The same is possibly true also of signed and
> unsigned integers!?!
>
> IOW the /language/ would define the precedences and associativity of
> operator symbols or standard names but the meaning of those operators
> would be defined /externally/.
>
> The second point is that named prefix operations such as ABS and SIN -
> and many like them - would not need to be part of the language. For one
> thing, they could be defined in external modules and, for another, they
> would appear best as functions rather than as operators. For example, in
>
>   abs(y)
>
> the abs function referred to would depend on whether y was an int or a
> float, and a call such as
>
>   sin(x)
>
> would work for x being a float but the name "sin" would be undefined if
> x were an integer.
>
>
>
> Going back to the calculator, aside from common operations surely most
> of the more obscure actions one could find on a calculator such as
> statistical and financial operations would be most clearly expressed in
> code by
>
>   op_name(args)
>
> Further, that 'named prefix' form allows any number of functions to be
> apply-able to the types of its args. Possibly most of an advanced
> calculator's functions are unary, anyway, so the prefix form would be
> more appropriate.
>
> With function form there's no ambiguity about how any operations are
> applied and the names give a clue as to the meaning. For example,
>
>   factorial(x)
>
> gives a big clue as to what it might do....!
>
>
>
> In sum, perhaps it would be better to build common operators into type
> libraries and not make them part of the language itself.

I think I've made my view known on this!

You need a more complicated implementation, and one that implements more
advanced optimisations, which are going to be slower, to get code of the
same standard as you can get easily when things are built-in.

The point of my calculator link was that, while it was a programmable
calculator that could conceivably be used to implement ABS (which is an
easy function actually), they still provided an ABS button anyway.

Now, it's possible that there is an OEM maker of calculators that takes
delivery of unbranded programmable calculators where many buttons are
blank. And they decide what 'built-in' functions should be provided on
those buttons. The devices are supplied with those already programmed.

If languages took the same approach, then that's fine. The user won't
know any different (except it might be slower). And they will be using
apparently the same named language as other people, so they can easily
share code.

Except that languages don't like to draw that line and make those OEM
facilities available to everyone; each person creates their own language
with its own unwieldy set of half-implemented features.

On 21/11/2021 18:55, James Harris wrote:
> This is to follow up on comments from another thread. It's prompted by a picture
> of a calculator which Bart posted:
>
> https://upload.wikimedia.org/wikipedia/commons/9/9c/Hp35s_Calculator.jpg
>
> I think the issue being discussed was what operators should be provided by a
> language. I'd suggest almost none!
>
> Don't get me wrong! AISI there should be standard operator /symbols/ such as +,
> *, >>, etc (and possibly some reserved operator words such as "and" and "or")
> and they should have precedences and associativities but that they should be
> semantically meaningless. Instead, they would be given meaning by the data types
> to which they are applied.
>
> That's not as strange as it may sound. In
>
>   A + B
>
> the meaning of + will depend on whether A and B are ints or floats - or,
> possibly, strings or some user-defined type.
>
> If the meaning depends on the types of the operands then it doesn't have to be
> built in but can be defined by code /for the requisite type/. For example, if A
> and B are floats and there's a definition for the type 'float' which includes
> the following

You are re-inventing Algol 68 again.

--
Charles H. Lindsey ---------At my New Home, still doing my own thing------
Tel: +44 161 488 1845 Web: https://www.clerew.man.ac.uk
Email: chl@clerew.man.ac.uk Snail-mail: Apt 40, SK8 5BF, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

On 21/11/2021 19:45, Bart wrote:
> On 21/11/2021 18:55, James Harris wrote:
>> In sum, perhaps it would be better to build common operators into
>> type libraries and not make them part of the language itself.

I agree with Charles!

> You need a more complicated implementation, and one that implements
> more advanced optimisations, which are going to be slower, to get
> code of the same standard as you can get easily when things are
> built-in.

Doesn't follow. The library can have access to parts of the
language that are not available to ordinary users, inc [eg] escapes
into assembler, inlining, access to the compiler's internal structures,
...., and can be optimised when the compiler is built. The point is to
keep the language definition simple, not cluttered [as are, eg, Pascal
and C] by having to explain as part of the language what "add-ops" are
and how they relate to "mult-ops" or logical operators.

--
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

On 22/11/2021 20:34, Andy Walker wrote:
> On 21/11/2021 19:45, Bart wrote:
>> On 21/11/2021 18:55, James Harris wrote:
>>> In sum, perhaps it would be better to build common operators into
>>> type libraries and not make them part of the language itself.
>
>     I agree with Charles!
>
>> You need a more complicated implementation, and one that implements
>> more advanced optimisations, which are going to be slower, to get
>> code of the same standard as you can get easily when things are
>> built-in.
>
>     Doesn't follow.  The library can have access to parts of the
> language that are not available to ordinary users, inc [eg] escapes
> into assembler, inlining, access to the compiler's internal structures,
> ..., and can be optimised when the compiler is built.

This is my point: you need:

* Inline assemby
* Inlining
* User-defined operator overloads
* The equivalent of C++'s constexpr
* A gcc-class optimiser
....

Too many advanced compilers features, just to keep the language 'small'.

Yet the user will see the small core features plus the ones implemented
via language features; they will still see a big language.

Where's the advantage, and who benefits?

  The point is to
> keep the language definition simple,

What, like Algol68? They seemed to have gone out of their way to make
the definition imcomprehensible!

(My a68g.exe is 2.8MB; my nearest language is 0.5MB. Just saying...)

> not cluttered [as are, eg, Pascal
> and C] by having to explain as part of the language what "add-ops" are
> and how they relate to "mult-ops" or logical operators.
>

On 22/11/2021 14:26, Charles Lindsey wrote:

....

>
> You are re-inventing Algol 68 again.
>

I am not reinventing it ... but if I am going down some of the same
lines then that's probably a good thing.

I have yet to reply to another post where you said the same, and I think
my reply to that may be similar to what Algol means by returning an
object rather than its value so maybe the similarities continue!

--
James Harris

On 22/11/2021 23:08, Bart wrote:
> On 22/11/2021 20:34, Andy Walker wrote:
>> On 21/11/2021 19:45, Bart wrote:
>>> On 21/11/2021 18:55, James Harris wrote:

>>>> In sum, perhaps it would be better to build common operators into
>>>> type libraries and not make them part of the language itself.

....

>>> You need a more complicated implementation, and one that implements
>>> more advanced optimisations, which are going to be slower, to get
>>> code of the same standard as you can get easily when things are
>>> built-in.
>>
>>      Doesn't follow.  The library can have access to parts of the
>> language that are not available to ordinary users, inc [eg] escapes
>> into assembler, inlining, access to the compiler's internal structures,
>> ..., and can be optimised when the compiler is built.
>
> This is my point: you need:
>
> * Inline assemby
> * Inlining
> * User-defined operator overloads
> * The equivalent of C++'s constexpr
> * A gcc-class optimiser

I don't see why Andy says there should be escapes to assembly and I'd
question your list, too.

I've got work to do on this, as yet, but here's how I see it starting.
AFAIK it's a novel approach so may need some synapse rewiring. :-)

A 'type library' would include code for each operator of that type. For
instance imagine that an expression such as

A + B

has A and B of the same type as each other. Let's say it's float. In the
type library for float there will be code for

<float> + <float> => <float>

The library would be responsible for generating the right IR. For
example, if we assume that 'wider' floats can hold all the values of
narrower ones and (to make this not too simple) we further assume that
the language specification says that float addition is performed to the
resolution of the widest of the two operands then the IR generation
might be along the lines of the following.

w = max(A._width, B._width)
IR.widen(A1, A, w)
IR.widen(B1, B, w)
IR.declare(float, w, Result)
IR.float_add(Result, A1, B1)

What that is intended to do is to work out the maximum width of A and B,
widen the narrower one (if any) to that width, declare a variable called
Result which has that width, then carry out the addition into Result.

Note where this sits in the compile process. The calls to IR routines
would populate the parse tree.

Note, also, that the tree would include noops such as those to widen a
64-bit float to another 64-bit float but such noops would disappear as
part of optimisation.

Above all, note that the code is at high level and not particularly
complicated. All it's really doing is adding operations to the parse tree.

> ...
>
> Too many advanced compilers features, just to keep the language 'small'.

For sure, the compiler would have the above complication. But the
handling of all data types could be written in the same way.

>
> Yet the user will see the small core features plus the ones implemented
> via language features; they will still see a big language.

Not at all. I see it as a benefit for a programmer to be able to
distinguish between language and libraries, and for the language to be
kept small.

>
> Where's the advantage, and who benefits?

The model is different, I grant you, but conceptually simple. And it's
more consistent. All data types - those inbuilt, those provided in
standard libraries, and those the programmer writes - would be treated
in the same way.

Further, the IR-generating code is simple enough that anyone who wanted
to see the details of how an operation would be implemented can go read
it! Maybe it would be enough to satisfy the language lawyers. :-)

I should say the above is work in progress. I am not committed to it
yet. One problem I still have is essentially overloading (that old
chestnut) and how to distinguish bound from unbound functions. (Bound
would be defined in a library for the type of their first argument.
Unbound would not. Yet calls to them might look remarkably similar....)

Flak jacket at the ready!

--
James Harris

On 2021-11-23 17:39, James Harris wrote:

> One problem I still have is essentially overloading (that old
> chestnut) and how to distinguish bound from unbound functions. (Bound
> would be defined in a library for the type of their first argument.
> Unbound would not. Yet calls to them might look remarkably similar....)

The terms are "method" vs "free function."

Dedicated argument makes no sense, obviously. It is motivated by
inability to implement multiple dispatch, serves as an excuse.

One answer is per types. Free function would be defined on the whole
class, that makes them distinguishable as the type would be different.

Most languages allow free functions with the same type, arguably they
should not [unless inside the private implementation]. This again is
problematic with modules and multiple dispatch.

So, basically, the issue is wide open to debate and there is no workable
concept in sight.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 23/11/2021 17:44, Dmitry A. Kazakov wrote:
> On 2021-11-23 17:39, James Harris wrote:
>
>> One problem I still have is essentially overloading (that old
>> chestnut) and how to distinguish bound from unbound functions. (Bound
>> would be defined in a library for the type of their first argument.
>> Unbound would not. Yet calls to them might look remarkably similar....)
>
> The terms are "method" vs "free function."

Maybe, although I think of methods as going along with classes, and
there are no classes (at least no inheritance) in what I have in mind.

>
> Dedicated argument makes no sense, obviously. It is motivated by
> inability to implement multiple dispatch, serves as an excuse.

I don't think I'd want multiple dispatch. As discussed elsewhere it
cannot scale well. At most, ISTM, one could select a routine based on
two types: that of one argument and that of the result, though in most
cases one would use only the type of one argument.

For sure, if something more complicated is required a routine could do
what I think you called double dispatch switching between different
implementations based on the types of any further arguments it wanted
(i.e. any arguments after the first). You had concerns that it would be
slow but AFAICS it would involve two dispatches which were about as fast
as possible and it would scale much better than multiple dispatch.

>
> One answer is per types. Free function would be defined on the whole
> class, that makes them distinguishable as the type would be different.

What about the syntax of invocation? In

a = F(b, c)

it might be that F is bound to the type of its first argument, b, or it
might be that the programmer has defined F as an unbound function with
two parameters. There's nothing in the source to indicate which is
meant, and that seems to be a problem.

>
> Most languages allow free functions with the same type, arguably they
> should not [unless inside the private implementation]. This again is
> problematic with modules and multiple dispatch.
>
> So, basically, the issue is wide open to debate and there is no workable
> concept in sight.

Understood. It's reassuring to hear you say so...!

--
James Harris

On 2021-11-23 21:38, James Harris wrote:
> On 23/11/2021 17:44, Dmitry A. Kazakov wrote:
>> On 2021-11-23 17:39, James Harris wrote:
>>
>>> One problem I still have is essentially overloading (that old
>>> chestnut) and how to distinguish bound from unbound functions. (Bound
>>> would be defined in a library for the type of their first argument.
>>> Unbound would not. Yet calls to them might look remarkably similar....)
>>
>> The terms are "method" vs "free function."
>
> Maybe, although I think of methods as going along with classes, and
> there are no classes (at least no inheritance) in what I have in mind.

You have it the form of implicit type conversions. Say you convert float
to double and have a function Foo defined on double and accepting float.
This Foo is a sort of method for the class {float, double}.

In C this is consistent because C does this *always*. Unless you do
same, you would have a massive problem that whether a conversion apply
could depend on the actual visibility context.

>> One answer is per types. Free function would be defined on the whole
>> class, that makes them distinguishable as the type would be different.
>
> What about the syntax of invocation? In
>
>   a = F(b, c)
>
> it might be that F is bound to the type of its first argument, b, or it
> might be that the programmer has defined F as an unbound function with
> two parameters. There's nothing in the source to indicate which is
> meant, and that seems to be a problem.

There is no problem. Let we have three types:

T1 a
T2 b
T3 c

Now, let F be not a method of b. This is what you mean, right?

The first argument of F would be class T2 rather than simple T2. It
means that b will be "converted" to the class. [Under the model that b
keeps the type tag it is null conversion.] Then inside F it will
dispatch to the methods of T2.

Thus regardless on any visibility the semantics F regarding b could not
change.

Methods persist and class-wide operations are always reduced to method
calls, which makes it safe.

Free functions of simple types in presence of classes of any kind is
asking for trouble.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 23/11/2021 16:39, James Harris wrote:
> On 22/11/2021 23:08, Bart wrote:
>> On 22/11/2021 20:34, Andy Walker wrote:
>>>      Doesn't follow.  The library can have access to parts of the
>>> language that are not available to ordinary users, inc [eg] escapes
>>> into assembler, inlining, access to the compiler's internal structures,
>>> ..., and can be optimised when the compiler is built.
>> This is my point: you need:
>> * Inline assemby
[...]
> I don't see why Andy says there should be escapes to assembly and I'd
> question your list, too.

Andy didn't say there should be, but that there can be. IOW,
a [system or standard] library can do things that ordinary user code
can't; in particular it can know more than ordinary users about the
compiler internals. Whatever Bart expects his compiler to do about
[eg] standard operators can equally be done by the library. It's a
matter of taste whether the library is tightly integrated with the
compiler proper, or is more loosely connected [cf whether a multi-
pass compiler consists of a chain of completely separate programs
or is a collection of modules linked together into one executable].
There are pros and cons either way.

[For "assembly" read your IR if you prefer. It's just that
I was brought up with languages where you could use assembler codes
directly in your program. (Eg, A68R, the Malvern compiler, had
"CODE ... EDOC" brackets within which you could use ICL 1900 op codes,
augmented by symbolic access to your program's variables.) C was the
first language I used extensively in which this was not possible, but
instead you had to write (PDP 11) assembler modules which then got
linked in to your C.]

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

On 22/11/2021 23:08, Bart wrote:
>>> You need a more complicated implementation, and one that implements
>>> more advanced optimisations, which are going to be slower, to get
>>> code of the same standard as you can get easily when things are
>>> built-in.
>>      Doesn't follow.  The library can have access to parts of the
>> language that are not available to ordinary users, inc [eg] escapes
>> into assembler, inlining, access to the compiler's internal structures,
>> ..., and can be optimised when the compiler is built.
> This is my point: you need:
> * Inline assemby
> * Inlining
> * User-defined operator overloads

[You don't need user-defined overloads unless your language
includes them. In which case you need them because of the language,
not because you've implemented them in a library.]

> * The equivalent of C++'s constexpr
> * A gcc-class optimiser
> ...
> Too many advanced compilers features, just to keep the language 'small'.

If you're going to have these things, you need them anyway.
There is no clear-cut boundary between what compilers do and what
goes into a standard library. It doesn't matter whether it's the
compiler that decides that "A + B" turns into "load A, load B, add"
or the library that decides that. In either case, syntax analysis
produces a node in the parse tree consisting of an operator and its
two [in this case] operands, or some near equivalent to that. How
that gets processed further is a matter of taste.

> Yet the user will see the small core features plus the ones
> implemented via language features; they will still see a big
> language.

It isn't a "big language" if the syntax is small and simple.
The problem for users is not usually checking through the list of
library routines to see if there's one to multiply matrices or to
open a window, but is knowing precisely how to write loops or to
declare arrays of pointers to procedures.

> Where's the advantage, and who benefits?

Logical separation; careful users.

>> The point is to
>> keep the language definition simple,
> What, like Algol68? They seemed to have gone out of their way to make
> the definition imcomprehensible!

That is because some people went out of their way to claim
that it is incomprehensible, and others more recently [no names, no
pack drill] still go out of their way to ask me what a semicolon
means instead of looking it up themselves. The Watt-Peck-Sintzoff
chart in Algol Bulletin gets the A68 syntax onto one side; the
A68R User Guide gets it, in larger type and with lots of white
space, into well under two sides; substantially less than usual
representations of C, Pascal, Ada, ....

> (My a68g.exe is 2.8MB; my nearest language is 0.5MB. Just saying...)
My copy of "a68g" [2.8.4] is 1183284 bytes; it has crept
up over the decades from the 504749 bytes of 1.4.0, the earliest
A68G version I have. Algol itself hasn't changed, and A68G "then"
was missing only a few minor features, so I expect the increase
comes primarily from (a) much more extensive checking, (b) extra
language features such as partial parametrisation and the Torrix
extensions, and (c) additional library features such as Plotutils,
PostgreSQL, linear algebra, and many others. I expect that if
your language included such things, it too would grow from 0.5MB
to around 1MB.

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

On 23/11/2021 21:34, Dmitry A. Kazakov wrote:
> On 2021-11-23 21:38, James Harris wrote:
>> On 23/11/2021 17:44, Dmitry A. Kazakov wrote:
>>> On 2021-11-23 17:39, James Harris wrote:

....

>> What about the syntax of invocation? In
>>
>>    a = F(b, c)
>>
>> it might be that F is bound to the type of its first argument, b, or
>> it might be that the programmer has defined F as an unbound function
>> with two parameters. There's nothing in the source to indicate which
>> is meant, and that seems to be a problem.
>
> There is no problem. Let we have three types:
>
>    T1 a
>    T2 b
>    T3 c
>
> Now, let F be not a method of b. This is what you mean, right?

I can't be sure whether you meant to say "not" in that but the idea is
that the definition of type T2 would include at least one function
called F as in

type T2
function F

>
> The first argument of F would be class T2 rather than simple T2.

I don't know about that. AFAICS the first argument of F would be of
/type/ T2. That's all.

The problem I have is that F could be defined within type T2 (i.e.
'bound' to T2) as in

type T2
function F(....)

or it could be a plain ('unbound') function as in

function F(T2 x, ....)

I am uncomfortable about having a function called F potentially findable
in two completely different places.

What to do? I don't know. AFAICS both forms of function definition have
their uses - and programmers are used to both forms.

Am open to suggestions!

> It
> means that b will be "converted" to the class. [Under the model that b
> keeps the type tag it is null conversion.] Then inside F it will
> dispatch to the methods of T2.
>
> Thus regardless on any visibility the semantics F regarding b could not
> change.
>
> Methods persist and class-wide operations are always reduced to method
> calls, which makes it safe.
>
> Free functions of simple types in presence of classes of any kind is
> asking for trouble.
>

The trouble is that some functions are naturally free/unbound, i.e. they
either don't have any parameters or they are not naturally bound to the
type of their first parameter so in a call such as

F(x)

there's no way to tell whether F is free/bound or non-free/unbound.

--
James Harris

On 2021-11-24 11:06, James Harris wrote:
> On 23/11/2021 21:34, Dmitry A. Kazakov wrote:
>> On 2021-11-23 21:38, James Harris wrote:
>>> On 23/11/2021 17:44, Dmitry A. Kazakov wrote:
>>>> On 2021-11-23 17:39, James Harris wrote:
>
> ...
>
>>> What about the syntax of invocation? In
>>>
>>>    a = F(b, c)
>>>
>>> it might be that F is bound to the type of its first argument, b, or
>>> it might be that the programmer has defined F as an unbound function
>>> with two parameters. There's nothing in the source to indicate which
>>> is meant, and that seems to be a problem.
>>
>> There is no problem. Let we have three types:
>>
>>     T1 a
>>     T2 b
>>     T3 c
>>
>> Now, let F be not a method of b. This is what you mean, right?
>
> I can't be sure whether you meant to say "not" in that but the idea is
> that the definition of type T2 would include at least one function
> called F as in
>
>   type T2
>     function F

You are talking about [misfortunate] lexical elements of your language.
The question is the semantics of these. I guessed that this construct
would imply that F is a method in T2 argument/result and when F declared
outside would be not, i.e. a free function.

>> The first argument of F would be class T2 rather than simple T2.
>
> I don't know about that. AFAICS the first argument of F would be of
> /type/ T2. That's all.

That means a plain free function, which has all problems expected. You
get what you asked for.

> What to do? I don't know. AFAICS both forms of function definition have
> their uses - and programmers are used to both forms.
>
> Am open to suggestions!

I already explained that. If F were class-wide in b, it would have no
such problems because it would always go back to the methods. Any
type-specific argument or result, or if you want alternative
terminology, any *contravariant* argument, is a trouble in presence of
classes of whatever origin. Drop classes and you will have no problems.
Keep classes (implicit conversions included) and you will have problems
with contravariance. OK?

> The trouble is that some functions are naturally free/unbound, i.e. they
> either don't have any parameters or they are not naturally bound to the
> type of their first parameter so in a call such as
>
>   F(x)
>
> there's no way to tell whether F is free/bound or non-free/unbound.

Why should anybody care? It tells do F on x. The effect is determined by
the type of x. Qualifiers like "bound" are implementation details at
best, otherwise meaningless.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 24/11/2021 11:18, Dmitry A. Kazakov wrote:
> On 2021-11-24 11:06, James Harris wrote:
>> On 23/11/2021 21:34, Dmitry A. Kazakov wrote:
>>> On 2021-11-23 21:38, James Harris wrote:
>>>> On 23/11/2021 17:44, Dmitry A. Kazakov wrote:
>>>>> On 2021-11-23 17:39, James Harris wrote:
>>
>> ...
>>
>>>> What about the syntax of invocation? In
>>>>
>>>>    a = F(b, c)
>>>>
>>>> it might be that F is bound to the type of its first argument, b, or
>>>> it might be that the programmer has defined F as an unbound function
>>>> with two parameters. There's nothing in the source to indicate which
>>>> is meant, and that seems to be a problem.
>>>
>>> There is no problem. Let we have three types:
>>>
>>>     T1 a
>>>     T2 b
>>>     T3 c
>>>
>>> Now, let F be not a method of b. This is what you mean, right?
>>
>> I can't be sure whether you meant to say "not" in that but the idea is
>> that the definition of type T2 would include at least one function
>> called F as in
>>
>>    type T2
>>      function F
>
> You are talking about [misfortunate] lexical elements of your language.
> The question is the semantics of these.

I was illustrating semantics. With pseudocode. Nothing to do with
lexical elements.

> I guessed that this construct
> would imply that F is a method in T2 argument/result and when F declared
> outside would be not, i.e. a free function.

Yes.

>
>>> The first argument of F would be class T2 rather than simple T2.
>>
>> I don't know about that. AFAICS the first argument of F would be of
>> /type/ T2. That's all.
>
> That means a plain free function, which has all problems expected. You
> get what you asked for.

It is not possible to make all functions bound. For example,

time_now()

or

emit_newline()

cannot be bound to the types of their first parameters because neither
has a first parameter.

>
>> What to do? I don't know. AFAICS both forms of function definition
>> have their uses - and programmers are used to both forms.
>>
>> Am open to suggestions!
>
> I already explained that. If F were class-wide in b, it would have no
> such problems because it would always go back to the methods. Any
> type-specific argument or result, or if you want alternative
> terminology, any *contravariant* argument, is a trouble in presence of
> classes of whatever origin. Drop classes and you will have no problems.
> Keep classes (implicit conversions included) and you will have problems
> with contravariance. OK?

Unfortunately, what you explained doesn't see to match because you are
using terms (such as contravariance) associated with subtyping when
there is no subtyping in the problem! And it's left me mystified as to
how all those terms relate to the issue at hand - if at all. :-(

When you explain things it might help if you were to do so in terms of
the mechanics rather than in terms of buzzwords/jargon.

>
>> The trouble is that some functions are naturally free/unbound, i.e.
>> they either don't have any parameters or they are not naturally bound
>> to the type of their first parameter so in a call such as
>>
>>    F(x)
>>
>> there's no way to tell whether F is free/bound or non-free/unbound.
>
> Why should anybody care? It tells do F on x. The effect is determined by
> the type of x. Qualifiers like "bound" are implementation details at
> best, otherwise meaningless.
>

Well, if you saw

F(x)

where would you as a programmer look to find where F was defined?

Similarly, if F were to be defined in two places as in

type T2
function F....

and

function(T2 F, ....)

which one should the F(x) in

T2 x
F(x)

invoke?

As it happens, I am thinking that perhaps I should just accept that
programmers would want to use both forms but then what happens if the
same name is defined in both ways? Does one take precedence? Should the
compiler (or the linker if from separate modules) flag an error?

It may be worth bearing in mind that the bound form can always be
accessed via the type as in

T2.F

or

(typeof x).F

By contrast, I suppose that the unbound form could be accessed by means
of whatever contains it such as

namespace N
function F

N.F

so even if the same name were defined in both ways there would always be
a way to specify one or the other - with the bound form being easiest to
specify.

--
James Harris

On 2021-11-24 16:35, James Harris wrote:
> On 24/11/2021 11:18, Dmitry A. Kazakov wrote:

>> That means a plain free function, which has all problems expected. You
>> get what you asked for.
>
> It is not possible to make all functions bound. For example,
>
>   time_now()
>
> or
>
>   emit_newline()
>
> cannot be bound to the types of their first parameters because neither
> has a first parameter.

emit_newline() does not have problems either as there is no class involved.

time_now() has the result, which has a type and if this type is a member
of a class, you have all problems back. The class could be like

{ Calendar_Zoned_Time, UTC_Time, Monotonic_Real_Time }

>> I already explained that. If F were class-wide in b, it would have no
>> such problems because it would always go back to the methods. Any
>> type-specific argument or result, or if you want alternative
>> terminology, any *contravariant* argument, is a trouble in presence of
>> classes of whatever origin. Drop classes and you will have no
>> problems. Keep classes (implicit conversions included) and you will
>> have problems with contravariance. OK?
>
> Unfortunately, what you explained doesn't see to match because you are
> using terms (such as contravariance) associated with subtyping when
> there is no subtyping in the problem! And it's left me mystified as to
> how all those terms relate to the issue at hand - if at all. :-(

As I said, no classes no problems. Your "bondage" stuff loses sense
without classes. It makes no difference how you declare subprograms and
where back in FORTRAN-IV. You want FORTRAN-IV be FORTRAN-IV! You want
more, learn the meaning of the "buzz words"...

> When you explain things it might help if you were to do so in terms of
> the mechanics rather than in terms of buzzwords/jargon.

All mechanics was explained 100 times over. You just skipped it all 100
times.

>> Why should anybody care? It tells do F on x. The effect is determined
>> by the type of x. Qualifiers like "bound" are implementation details
>> at best, otherwise meaningless.
>
> Well, if you saw
>
>   F(x)
>
> where would you as a programmer look to find where F was defined?

Right-mouse click -> "go to definition" It was a stupid question, really.

> Similarly, if F were to be defined in two places as in
>
>   type T2
>     function F....
>
> and
>
>   function(T2 F, ....)

I have no idea what the second is supposed to mean, a cat walking the
keyboard?

> which one should the F(x) in
>
>   T2 x
>   F(x)
>
> invoke?

The one declared on the type T2, obviously. Sorry, this question looks
even more stupid to me.

[...]

> so even if the same name were defined in both ways there would always be
> a way to specify one or the other - with the bound form being easiest to
> specify.

Free functions is trouble in presence of classes, that was established.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 24/11/2021 00:04, Andy Walker wrote:
> On 22/11/2021 23:08, Bart wrote:
>>>> You need a more complicated implementation, and one that implements
>>>> more advanced optimisations, which are going to be slower, to get
>>>> code of the same standard as you can get easily when things are
>>>> built-in.
>>>      Doesn't follow.  The library can have access to parts of the
>>> language that are not available to ordinary users, inc [eg] escapes
>>> into assembler, inlining, access to the compiler's internal structures,
>>> ..., and can be optimised when the compiler is built.
>> This is my point: you need:
>> * Inline assemby
>> * Inlining
>> * User-defined operator overloads
>
>     [You don't need user-defined overloads unless your language
> includes them.  In which case you need them because of the language,
> not because you've implemented them in a library.]

If you want to have an overloaded 'abs' operator or function available
to the user of the language (so I'm not specifying how), then if it's
not built-in, it will need the ability to do user-overloads, plus
inlining if you want it as efficient.

>> * The equivalent of C++'s constexpr
>> * A gcc-class optimiser
>> ...
>> Too many advanced compilers features, just to keep the language 'small'.
>
>     If you're going to have these things, you need them anyway.
> There is no clear-cut boundary between what compilers do and what
> goes into a standard library.  It doesn't matter whether it's the
> compiler that decides that "A + B" turns into "load A, load B, add"
> or the library that decides that.

It matters very much. My static language is self-hosted, and can build
itself entirely from source fast enough that I could do so ten times
every second if I was so inclined.

To me that is important; not that I need to do that 600 times a minute,
but it means an effectively zero edit-build-run cycle for similar-sized
applications.

That would be harder to achieve using the wrong language choices; it
would also take longer, and the result would build apps more slowly.

>  In either case, syntax analysis
> produces a node in the parse tree consisting of an operator and its
> two [in this case] operands, or some near equivalent to that.  How
> that gets processed further is a matter of taste.

Fine. So you don't care exactly how the language makes standard language
features appear as though they are built-in. So there's no problem.

>> What, like Algol68? They seemed to have gone out of their way to make
>> the definition imcomprehensible!
>
>     That is because some people went out of their way to claim
> that it is incomprehensible,

I hadn't look at the report for years, and forgotten what it was like.

But I did recently glimpse it again at the back of that PDF. The first
thing you see is it talking about Protonotion, Metanotion, and Hypernotion.

A few pages further on, it's on about Moid, Mood and Mu.

You can't help but think that this is a language takes itself too
seriously! (I have also considered that it might all have been an
eloborate joke.)

An interesting exercise would be to take the language and create a new
definition without all those fancy terms.

The language, as far as I can see, doesn't offer abilities that are
particularly unusual or hard to understand, certainly amongst the
current crop of languages. It should therefore have a more down-to-earth
definition.

> and others more recently [no names, no
> pack drill] still go out of their way to ask me what a semicolon
> means instead of looking it up themselves.

Commas have the usual expected use in languages that employ them.

AFAICS in Algol68, ";" and "," can both be used to separate things, but
"A;B" means do A then B, but "A,B" do A and B, in either order or
concurrently.

Whether that applies to A[i,j,k] or F(a,b,c), I don't know.

However, it doesn't like F(a;b;c) when three arguments are expected. So
there is something more to it.

(Don't bother to explain; I'm never going to get it. I'm just not
surprised that Wirth left the Algol68 (or 'new Algol') group and
produced his own simpler language.)

  The Watt-Peck-Sintzoff
> chart in Algol Bulletin gets the A68 syntax onto one side;  the
> A68R User Guide gets it, in larger type and with lots of white
> space, into well under two sides;  substantially less than usual
> representations of C, Pascal, Ada, ....
>
>> (My a68g.exe is 2.8MB; my nearest language is 0.5MB. Just saying...)
>     My copy of "a68g" [2.8.4] is 1183284 bytes;  it has crept
> up over the decades from the 504749 bytes of 1.4.0, the earliest
> A68G version I have.  Algol itself hasn't changed, and A68G "then"
> was missing only a few minor features, so I expect the increase
> comes primarily from (a) much more extensive checking, (b) extra
> language features such as partial parametrisation and the Torrix
> extensions, and (c) additional library features such as Plotutils,
> PostgreSQL, linear algebra, and many others.  I expect that if
> your language included such things, it too would grow from 0.5MB
> to around 1MB.

Yeah I think this has come up before.

The reality is that the languages (either of mine, both 0.5MB) are too
different to do a meaningful comparison. A68 has lots of features I
don't, and I have quite a few missing in A68).

One point of similarity however is the use of a single, self-contained
executable.

On 24/11/2021 16:08, Dmitry A. Kazakov wrote:
> On 2021-11-24 16:35, James Harris wrote:
>> On 24/11/2021 11:18, Dmitry A. Kazakov wrote:

....

>>> I already explained that. If F were class-wide in b, it would have no
>>> such problems because it would always go back to the methods. Any
>>> type-specific argument or result, or if you want alternative
>>> terminology, any *contravariant* argument, is a trouble in presence
>>> of classes of whatever origin. Drop classes and you will have no
>>> problems. Keep classes (implicit conversions included) and you will
>>> have problems with contravariance. OK?
>>
>> Unfortunately, what you explained doesn't see to match because you are
>> using terms (such as contravariance) associated with subtyping when
>> there is no subtyping in the problem! And it's left me mystified as to
>> how all those terms relate to the issue at hand - if at all. :-(
>
> As I said, no classes no problems. Your "bondage" stuff loses sense
> without classes. It makes no difference how you declare subprograms and
> where back in FORTRAN-IV. You want FORTRAN-IV be FORTRAN-IV! You want
> more, learn the meaning of the "buzz words"...

I have tried to understand your use of buzzwords but quite apart from
you expecting others to know Ada lingo, in some cases I remember finding
that you use buzzwords differently from other people. So if you want to
obfuscate a meaning you are doing exactly the right thing.

The real world does not happen in jargon but in transformations of data
and data structures. It should always be possible to explain a concept
in terms of data structures or algorithms. Binding a name to a function
is a case in point and the process could be described by steps, not jargon.

>
>> When you explain things it might help if you were to do so in terms of
>> the mechanics rather than in terms of buzzwords/jargon.
>
> All mechanics was explained 100 times over. You just skipped it all 100
> times.

Rubbish. You may have used buzzwords 100 times but that does not
constitute an explanation.

....

>> Similarly, if F were to be defined in two places as in
>>
>>    type T2
>>      function F....
>>
>> and
>>
>>    function(T2 F, ....)
>
> I have no idea what the second is supposed to mean, a cat walking the
> keyboard?

Sorry, it was pseudo C syntax. The type name T2 preceding the identifier
F was meant to indicate that F would be of type T2. The point of the two
fragments of code was that in BOTH of them the first argument to F would
be of type T2. The problem, then, is to say which F would be invoked by

F(x)

where x was of type T2.

--
James Harris

On 2021-11-26 18:21, James Harris wrote:

> The real world does not happen in jargon but in transformations of data
> and data structures.

.... precisely described by that jargon.

>>> Similarly, if F were to be defined in two places as in
>>>
>>>    type T2
>>>      function F....
>>>
>>> and
>>>
>>>    function(T2 F, ....)
>>
>> I have no idea what the second is supposed to mean, a cat walking the
>> keyboard?
>
> Sorry, it was pseudo C syntax. The type name T2 preceding the identifier
> F was meant to indicate that F would be of type T2. The point of the two
> fragments of code was that in BOTH of them the first argument to F would
> be of type T2. The problem, then, is to say which F would be invoked by
>
>   F(x)
>
> where x was of type T2.

The call is ambiguous when F of both declarations is directly visible.

An important difference between a method and a free function is that
method cannot be hidden. If you see T2 or any object of you also see all
methods of T2.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 26/11/2021 20:05, Dmitry A. Kazakov wrote:
> On 2021-11-26 18:21, James Harris wrote:

....

>>>> Similarly, if F were to be defined in two places as in
>>>>
>>>>    type T2
>>>>      function F....
>>>>
>>>> and
>>>>
>>>>    function(T2 F, ....)
>>>
>>> I have no idea what the second is supposed to mean, a cat walking the
>>> keyboard?
>>
>> Sorry, it was pseudo C syntax. The type name T2 preceding the
>> identifier F was meant to indicate that F would be of type T2. The
>> point of the two fragments of code was that in BOTH of them the first
>> argument to F would be of type T2. The problem, then, is to say which
>> F would be invoked by
>>
>>    F(x)
>>
>> where x was of type T2.
>
> The call is ambiguous when F of both declarations is directly visible.

Indeed. The question is what to do about the ambiguity. Options:

1. Pick the F function found in the type.

2. Pick the F function which is 'unbound'.

3. If the two functions are defined in different scopes pick the one
which is 'closer in' to where F is invoked.

4. Reject the expression because of the ambiguity.

I do not know which approach would be best.

>
> An important difference between a method and a free function is that
> method cannot be hidden. If you see T2 or any object of you also see all
> methods of T2.

OK.

--
James Harris

On 24/11/2021 18:19, Bart wrote:
>>> * User-defined operator overloads
>>      [You don't need user-defined overloads unless your language
>> includes them.  In which case you need them because of the language,
>> not because you've implemented them in a library.]
> If you want to have an overloaded 'abs' operator or function
> available to the user of the language (so I'm not specifying how),
> then if it's not built-in, it will need the ability to do
> user-overloads, plus inlining if you want it as efficient.

"Available to the user" is not the same as "user-defined".
There are typically lots of things in a library that the user not
merely does not need to define but often cannot define within the
formal language. This typically includes basic types such as "int",
privileged calls to the OS, environment enquiries, generic types
[eg when "print" can take any type as parameter(s)], ....

[...]
>>> Too many advanced compilers features, just to keep the language 'small'.
>>      If you're going to have these things, you need them anyway.
>> There is no clear-cut boundary between what compilers do and what
>> goes into a standard library.  It doesn't matter whether it's the
>> compiler that decides that "A + B" turns into "load A, load B, add"
>> or the library that decides that.
> It matters very much. My static language is self-hosted, and can
> build itself entirely from source fast enough that I could do so ten
> times every second if I was so inclined.

So somewhere in your source there is code that says "A + B"
does not mean "pass A and B to a function called +" but instead notes
this as a special sort of node in the parse tree [or near equivalent]
and says "Aha! This compiles into ...". The effect is the same
whether this is built-in to the parser or is some "magic" in the
library. Which version is faster depends on how it is done; there
are pros and cons.

> To me that is important; not that I need to do that 600 times a
> minute, but it means an effectively zero edit-build-run cycle for
> similar-sized applications.

No, it means an effectively zero build-run part of that
cycle. If it was ten times slower, it would have negligible
effect on the whole cycle, unless it takes you less than a few
seconds to note the results of the run, work out what has gone
wrong [if anything], decide what you need to change, go to the
right place in the code, and type in the change. To which you
can [or should!] add the time needed to run regression tests,
and documentation. [I'm not saying that speed of compilation is
unimportant, of course.]

[A68:]
> But I did recently glimpse it again at the back of that PDF. The
> first thing you see is it talking about Protonotion, Metanotion, and
> Hypernotion.

Normal people largely skip that bit; it's just explaining
how two-level grammars work.

> A few pages further on, it's on about Moid, Mood and Mu.

Actually about "MOID", etc. That's the metalanguage, the
higher of the two levels. It's how you get an infinite set of
lower-level syntax rules, escape the tyranny of BNF, and check
as a matter of syntax that variables are declared, etc.

> You can't help but think that this is a language takes itself too
> seriously! (I have also considered that it might all have been an
> eloborate joke.)

You can't please everyone. A "MOID" is either a "MODE"
[type] or "void"; what should it be called, given that you want
to use it several hundred times? You want something short that
conveys the right general impression. No matter what you choose,
it will seem too jokey to some, too up itself to others.

> An interesting exercise would be to take the language and create a
> new definition without all those fancy terms.

Feel free. You could start with the brief syntax in the
"A68R User's Guide" or in [eg] "Introductory Algol 68 Programming".
But beware that the C standard and other similar documents are
several times longer, and nowhere near as definitive as the RR.

[...]
> AFAICS in Algol68, ";" and "," can both be used to separate things,
> but "A;B" means do A then B, but "A,B" do A and B, in either order or
> concurrently.
> Whether that applies to A[i,j,k] or F(a,b,c), I don't know.
> However, it doesn't like F(a;b;c) when three arguments are expected.
> So there is something more to it.

Of course there is more to it! You have supplied a serial
clause where a parameter pack is required. You can't expect just
to slap down random sequences of characters without understanding
what they are supposed to be -- in any language! -- and have it
work. AFAIK, no language I have ever used expects "A[i;j;k]" to
be an array element or "F(a;b;c)" to be the call of a function
with three parameters. I don't see any interesting distinction
between the way ";" and "," are used in Algol and the way they
are used in Pascal or C; ";" primarily to end a "statement" or
similar, and"," primarily to break up lists.

> (Don't bother to explain; I'm never going to get it. I'm just not
> surprised that Wirth left the Algol68 (or 'new Algol') group and
> produced his own simpler language.)

Well, simpler to compile, for sure. Simpler for new
programmers to learn or for experienced programmers to use?
Far from clear. Simpler to describe? People mocked the 236
pages of the RR [most of it comments, examples or the system
library] when it first came out -- until they found that proper
descriptions of other languages were at least as long, and
nowhere near as precise.

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

On 2021-11-26 22:56, James Harris wrote:

> Indeed. The question is what to do about the ambiguity. Options:
>
> 1. Pick the F function found in the type.
>
> 2. Pick the F function which is 'unbound'.
>
> 3. If the two functions are defined in different scopes pick the one
> which is 'closer in' to where F is invoked.
>
> 4. Reject the expression because of the ambiguity.
>
> I do not know which approach would be best.

Only #4 is valid.

What I tried to explain you with "buzz" words the solution is preventing
some ambiguities to appear by limiting free functions.

There are also other language design requirements regarding consistency
and unambiguity of program, especially similarly looking code in
different contexts or literally same generic code instantiated in
different contexts.

But I do not want to go into it, because it will be another spat about
"buzz" words.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 26/11/2021 22:00, Andy Walker wrote:
> On 24/11/2021 18:19, Bart wrote:
>>>> * User-defined operator overloads

>     So somewhere in your source there is code that says "A + B"
> does not mean "pass A and B to a function called +" but instead notes
> this as a special sort of node in the parse tree [or near equivalent]
> and says "Aha!  This compiles into ...".  The effect is the same
> whether this is built-in to the parser or is some "magic" in the
> library.  Which version is faster depends on how it is done;  there
> are pros and cons.

Imagine if you were creating the bytecode for an interpreter. Bytecode
execution is already slow enough, you will surely want a dedicated
instruction for a such a common operation, rather than involve a
call/return sequence plus whatever other instructions are needed.

Well, the bytecode for my interpeter [and many others!] has such an ADD
instruction. So does the VM used by my compiler, and knows what is it
early on. Very early in fact; this table entry links 'addsym', a lexer
token, with 'kadd', the VM op for ADD:

(addsym, "+", bin_op, kadd, kaddto, 4, 1),

Why not specify it straightaway instead of going around the houses?

(The '4' is a precedence level, and the '1' indicates it can start an
expression. The 'kaddto' is an auxiliary bytecode for when used as
'+:='; that is built-in too.)

>> To me that is important; not that I need to do that 600 times a
>> minute, but it means an effectively zero edit-build-run cycle for
>> similar-sized applications.
>
>     No, it means an effectively zero build-run part of that
> cycle.  If it was ten times slower, it would have negligible
> effect on the whole cycle,

For a few years, I worked with an interpreted compiler. That was usable,
most compiles /of a module/ took 0.5 seconds or less.

(That it was usable at all was also thanks to the simple compilation
techniques I favoured.)

But that was with separate compilation. I wanted the advantages of a
whole-program compiler, so it had to be faster if I didn't want the
annoyance of waiting several seconds for each build.

So I switched to native, and got 20 times faster.

Why would I want to make it slower? It means the approach is scalable to
programs 10 times the size (it might take 1-2 seconds) before build
delays become intolerable, when I'd need some more speedups.

That is more interesting than inventing ways for the compiler to get slower.

(Yes I know that many people with much bigger projects and much slower
compilers have to wait minutes. That is partly up to them, but I feel
sorry for the people working with Rust now. I would switch language to
increase productivity and a more lively environment.)

> unless it takes you less than a few
> seconds to note the results of the run, work out what has gone
> wrong [if anything], decide what you need to change, go to the
> right place in the code, and type in the change.

With near-instant compilation you develop different ways of working. I
might edit, build and re-run just to the spacing right or fix some
annoying detail, which could take multiple builds a few seconds apart.

Also, doing nothing for several seconds interrupts your concentration.

> [A68:]
>> But I did recently glimpse it again at the back of that PDF. The
>> first thing you see is it talking about Protonotion, Metanotion, and
>> Hypernotion.
>
>     Normal people largely skip that bit;  it's just explaining
> how two-level grammars work.

(Did you mean Normally rather than Normal?)

>> A few pages further on, it's on about Moid, Mood and Mu.
>
>     Actually about "MOID", etc.  That's the metalanguage, the
> higher of the two levels.  It's how you get an infinite set of
> lower-level syntax rules, escape the tyranny of BNF, and check
> as a matter of syntax that variables are declared, etc.

Except that it isn't a matter of syntax; that's too constraining.(But
didn't you say its syntax could be described in 1-2 pages?)

>> You can't help but think that this is a language takes itself too
>> seriously! (I have also considered that it might all have been an
>> eloborate joke.)
>
>     You can't please everyone.  A "MOID" is either a "MODE"
> [type] or "void";  what should it be called, given that you want
> to use it several hundred times?

A MODE. Especially if as you say, a MODE/VOID is used in 100s of places.

If it's necessary to discriminate at some point between VOID and any
other MODE, then do so more locally, or with a less silly-sounding name.

On 27/11/2021 01:21, Bart wrote:
[I wrote:]
>> So somewhere in your source there is code that says "A + B"
>> does not mean "pass A and B to a function called +" but instead notes
>> this as a special sort of node in the parse tree [or near equivalent]
>> and says "Aha! This compiles into ...". The effect is the same
>> whether this is built-in to the parser or is some "magic" in the
>> library. Which version is faster depends on how it is done; there
>> are pros and cons.
> Imagine if you were creating the bytecode for an interpreter.
> Bytecode execution is already slow enough, you will surely want a
> dedicated instruction for a such a common operation, rather than
> involve a call/return sequence plus whatever other instructions are
> needed.

??? Of course it is common for back-end interpreters to
have "add" instructions. That makes it less, rather than more,
important for the front end to do anything special with it. You
seem to be hung up in thinking that a library cannot do anything
but turn "A + B" into two parameters and a function call. If it
is integrated into the system, it has privileged access to the
innards of the compiler, the operating system, ....

> Well, the bytecode for my interpeter [and many others!] has such an
> ADD instruction. So does the VM used by my compiler, [...].
> Why not specify it straightaway instead of going around the houses?

You can. But it's not "around the houses" if it's a
library that emits that bytecode rather than some "magic" in
the syntax analysis. It's just a matter of choice where in the
processing that emitting takes place. There is also merit in
having the syntax analysis simpler and more general. There is
also merit in leaving optimisations to a back end. There is room
for different models! Your requirement for a monolith is perhaps
different from [eg] Gnu's requirement for lots of front ends for
a variety of languages feeding into a common module feeding into
lots of back ends for different hardware.

[...]
> So I switched to native, and got 20 times faster.
> Why would I want to make it slower?

No reason why you should; I was merely pointing out that
whether a compilation and run takes 0.01s [as a large majority of
mine do using Algol 68G, with most of the rest < 1s] or 1s makes
no interesting difference to the complete edit-compile-run cycle.
But you seem to be assuming that putting things into libraries is
/ipso facto/ significantly slower than building them in to the
syntax. It may be; or it could be faster; or it could make
absolutely no measurable difference, depending on implementation
details and other factors.

[...]
> With near-instant compilation you develop different ways of working.
> I might edit, build and re-run just to the spacing right or fix some
> annoying detail, which could take multiple builds a few seconds
> apart.

Sure; I do that. It is still the case that my cycles
are almost entirely taken up by the edit phase.

[...]
>> [A68:]
>>> But I did recently glimpse it again at the back of that PDF. The
>>> first thing you see is it talking about Protonotion, Metanotion, and
>>> Hypernotion.
>> Normal people largely skip that bit; it's just explaining
>> how two-level grammars work.
> (Did you mean Normally rather than Normal?)

No, I meant "normal". Perhaps you're one of those strange
people who read encyclopaedias by starting at "Aachen" and going
through to "zygote"? Most people skip things they don't understand
and perhaps come back to them when better placed.

>>> A few pages further on, it's on about Moid, Mood and Mu.
>> Actually about "MOID", etc. That's the metalanguage, the
>> higher of the two levels. It's how you get an infinite set of
>> lower-level syntax rules, escape the tyranny of BNF, and check
>> as a matter of syntax that variables are declared, etc.
> 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? 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?

> (But didn't you say its syntax could be described in 1-2 pages?)

Yes, in the same way that most standard languages can
be described [eg] by a few pages of EBNF supplemented by lots
of pages of semantics. The RR chooses instead to have lots
of pages of syntax and rather few of semantics. Where to put
the boundary is a grey area. But, broadly speaking, it's the
semantics that lead to imprecision and debates about what
something means.

[...]
>> You can't please everyone. A "MOID" is either a "MODE"
>> [type] or "void"; what should it be called, given that you want
>> to use it several hundred times?
> A MODE. Especially if as you say, a MODE/VOID is used in 100s of
> places.

"MODE" [without "void" -- not "VOID"] is also used all over
the place; so, for that matter, is "void" without "MODE".

> If it's necessary to discriminate at some point between VOID and any
> other MODE, then do so more locally, or with a less silly-sounding
> name.

It's necessary throughout the RR. All part of being
careful with use of language. You find "MOID" silly; most
of us just find it a little quirky, and surely better than
[eg] "MODEORVOID".

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

On 27/11/2021 22:19, Andy Walker wrote:
> On 27/11/2021 01:21, Bart wrote:
> [I wrote:]
>>>      So somewhere in your source there is code that says "A + B"
>>> does not mean "pass A and B to a function called +" but instead notes
>>> this as a special sort of node in the parse tree [or near equivalent]
>>> and says "Aha!  This compiles into ...".  The effect is the same
>>> whether this is built-in to the parser or is some "magic" in the
>>> library.  Which version is faster depends on how it is done;  there
>>> are pros and cons.
>> Imagine if you were creating the bytecode for an interpreter.
>> Bytecode execution is already slow enough, you will surely want a
>> dedicated instruction for a such a common operation, rather than
>> involve a call/return sequence plus whatever other instructions are
>> needed.
>
>         ???  Of course it is common for back-end interpreters to
> have "add" instructions.  That makes it less, rather than more,
> important for the front end to do anything special with it.  You
> seem to be hung up in thinking that a library cannot do anything
> but turn "A + B" into two parameters and a function call.  If it
> is integrated into the system, it has privileged access to the
> innards of the compiler, the operating system, ....

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.

Yet not long ago you seemed to keen to implement things like:

A +:= B

via operator-overload mechanisms expressed within the language itself.
And more recently that you wanted new comparison operators to be defined
the same way.

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!)

But it seems my approach is perfectly valid too.

>> Well, the bytecode for my interpeter [and many others!] has such an
>> ADD instruction. So does the VM used by my compiler, [...].
>> Why not specify it

>> So I switched to native, and got 20 times faster.
>> Why would I want to make it slower?
>
>         No reason why you should;  I was merely pointing out that
> whether a compilation and run takes 0.01s [as a large majority of
> mine do using Algol 68G, with most of the rest < 1s] or 1s makes
> no interesting difference to the complete edit-compile-run cycle.
> But you seem to be assuming that putting things into libraries is
> /ipso facto/ significantly slower than building them in to the
> syntax.  It may be;  or it could be faster;  or it could make
> absolutely no measurable difference, depending on implementation
> details and other factors.

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!

That's from cold; subsequent runs take 0.25 seconds; still only 20 lines
per second. Such products are cumbersome because they are so large, and
overheads mean even tiny programs take an annoying amount of time.

On normal-sized programs, it might do 14Klps unoptimised, or 3Klps at -O3.

The A68G manages up to a respectable 20Klps, although not spectacular
for an /interpreter/.

The products I make can manage 500Klps for my static language, and 1Mlps
for my interpreter.

With the intepreter, it needs to compile an entire program head of time
into bytecode, before it can start execution. It uses a bundled library
which is [currently] over 10K lines. At A68G speeds, every program would
take 0.5 seconds start-up time before it even started on the user's
application.

(That library largely provides graphics and image processing capabilities.)

A typical application of 25Kloc would take over a second start-up, an
annoying latency. Fortunately, at its actual speed, start-up delays only
start to be noticable when programs reach 100K lines, and then the delay
is minimal (around 1/10th of a second).

Now start to compare products that use tracing JIT-compilers, which
introduce enough overheads that on the wrong kind of application (not
enough localised bottlenecks), they can be slower than regular
interpreters with longer start-up times.

>> 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! 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?

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.

In my dynamic language, it doesn't care they might be undefined until
runtime.

Instead, Algol68 chooses the most complex approach all, that is hard to
understand and difficult to implement. You can tell it was created by
academics!

> 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.)

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 necessary throughout the RR.  All part of being
> careful with use of language.  You find "MOID" silly;  most
> of us just find it a little quirky,

The whole thing is quirky. What I can confidently say is that, to me,
that whole document is almost completely useless for any purpose.