On 07/11/2022 18:16, James Harris wrote:

...

> But now what about dereference? Should it also take precedence over the
> ++ operators or should it come after one or both? For instance, what
> should the following mean?
>
>   ++p^
>
> Should it be
>
>   (++p)^
>
> or
>
>   ++(p^)
>
> ?

Lightbulb moment! It occurred to me last night that although dereference
"is about" lvalues it doesn't actually take in an lvalue; it takes an
rvalue (i.e. if supplied an lvalue it will be 'converted' to an rvalue
before being input to the dereference operation). I had it wrongly
classified in my operators spreadsheet. Yet that feature of dereference
may help suggest where its precedence should put relative to the ++
operators, i.e. it should come after both of them.

If so, that makes the order

prefix ++ ;lvalue -> lvalue
postfix ++ ;lvalue -> rvalue
^ (dereference) ;rvalue ->

That may be the solution: to put those three operators in that order
relative to each other. I'll have to see how it would work out in
practice but it is certainly a decision with logical underpinnings.

Feel free to tell me if that order of precedences is bad!

I should say I omitted what dereference produces as the lvalue it
produces is lexically unrelated to any variable in the expression.

--
James Harris

On 08/11/2022 08:33, David Brown wrote:
> On 08/11/2022 01:15, Bart wrote:

>> (Unless you go out of /your/ way to ensure it doesn't pass. But you'd
>> be better off avoiding such code. There are a million ways of writing
>> nonsense code that cannot be prohibited by a compiler.)
>>
>
> Yes, because "gcc -Wall" is /so/ hard to write.

And it's SO hard for a compiler to just use that as a default! So it
stays safe for EVERYONE no matter how they invoke the compiler.

Take a function like this which I consider much more dangerous than
anything we've been discussing:

void fred() {}

My bcc compiler gives a hard error: "() params are not allowed". But
this works:

gcc c.c -c

OK, I'll have to write -Wall as you say:

gcc -Wall c.c -c

But, it still passes!

(So much existing code wrongly uses () to mean no parameters - thanks no
doubt to gcc's lax approach over decades - that I have to give bcc a
special option to enable it when it comes up.)

>  I mean, it takes hours
> extra work, far out of your way.  Write yourself a batch file with gcc
> flags - you could have done it 20 years ago and saved yourself and
> everyone else enormous effort.

Why do you expect people to have to themselves implement a chunk of the
compiler they're using?

And have to do so for every compiler - at one time I was using 7 or 8.
ALL of them should be doing their jobs properly without being told.

> A major point of a good programming language - aided by good tools - is
> to reduce the amount of bad code that is accepted.

Yeah. In my language, A[i] only works when A is an array; P^ (pointer
deref) only works when P is a pointer.

Sounds obvious when put like that, but in C anything goes; Allowing A^
and P[i] enables a huge amout of dangerous nonsense.

>> I mean that you will not get any C compilers to get it to work: all
>> report hard errors, and will not generate any code.
>>
>
> So it is prohibited by the language.

So is ++E + E++ prohibited by C or not? I'm none the wiser, but it
sounds like, it depends!

>> It may be confusing to look at, but look at ANY C source and you will
>> see complex expressions that are much harder to grok, like:
>>
>> OP(op,3f) { F = ((F&(SF|ZF|YF|XF|PF|CF))|((F&CF)<<4)|(A&(YF|XF)))^CF;
>>           }
>>
>> (Is it even an expression? I /think/ it's function definition.)
>
> Are you arguing that because some people write C code that is even
> harder to understand, the OP should allow these nonsense expressions in
> his language?  That "logic" is like saying that because there are bank
> robbers, people should be allowed to drunk-drive.

YOU are arguing that you shouldn't be allowed to compose certain
operators because the result might be confusing. But why single out
these particular ones?

That is, combinations of increment and deref. More importantly, how
exactly do you expect the language to do so? If the result is sound,
syntax-wise and type-wise, what criterea do you expect it to apply?

To be clear, the expression we are talking about isn't a nonsense one at
all and is perfectly well-behaved:

a := (10, 20, 30)

p:=^a[1] # p points to the 10

++(p++^) # step p to the 20 while incrementing the 10

println a # displays (11, 20, 30)
println p^ # displays 20

(This is dynamic scripting code.)

As for ++e + e++, while I would never write such a thing, I'm not going
to lose sleep over it. It that was banned, there are 99 other ways to
write code where behaviour depends on evaluation order:

#include <stdio.h>

int f1(void) {return puts("One");}
int f2(void) {return puts("Two");}
int f3(void) {return puts("Three");}

void f(int a, int b, int c){}

int main(void) {
f(f1(), f2(), f3());
}

This displays:

Three
Two
One

with gcc and bcc. With tcc, it shows:

One
Two
Three

I know what, let's ban functions! This is what you are saying. You're
throwing out the baby with the bathwater.

On 07/11/2022 16:34, David Brown wrote:
> On 07/11/2022 16:23, Bart wrote:
>> On 07/11/2022 14:58, David Brown wrote:
>>> On 07/11/2022 12:55, James Harris wrote:

...

>> gcc accepts this C code (when E, V are both ints):
>>
>>
>>      ++E + E++;
>>      V = V++;

...

> (You've had this explained to you a few hundred times over the last
> decade or so.  I know you get some kind of perverse pleasure out of find
> any way of making C and/or gcc look bad in your own eyes, but would you
> /please/ stop being such a petty child and stop writing things
> deliberately intended to confuse, mislead or annoy others?)

Steady on, old boy! Surely we can make comments here without getting too
personal.

...

>>>>    ++E++^
>>>>    ++E^++
>>
>>
>>> Make it a syntax error.
>>
>> The equivalent in C syntax for the first is:
>>
>>      ++*(P++);
>>
>> This compiles fine when P has type int* for example. It means this:
>>
>>    - Increment the pointe P
>>    - Increment the location that P now points to (using the * deref op)
>>
>> So no reason to prohibit anything; it is perfectly well-defined.
>
> There is good reason to prohibit it - you got it wrong, so despite being
> well-defined by the language, it is not clear code.
>
> The actual meaning of "++*(P++);" is :
>
>     1. Remember the original value of P - call it P_orig
>     2. Increment P (that is, add sizeof(*P) to it).
>     3. Increment the int at the location pointed to by P_orig.
>     4. The value of the expression is the new updated value pointed to
> by P_orig.

That's a good example of how legitimate code can me made to look like
gibberish by the evil programmer (tm). As I've mentioned elsewhere it's
hard to invent rules to prohibit particular constructs simply because
'we don't like the look of them' and it would make the language harder
to implement and understand if the language design included rules on
'aesthetics'.

It seems to have parallels with the free-speech debate. Free speech is
easy when we get to choose what should be free and what should be banned
- but then that's not free speech. In reality, free speech is hard
because others may be free to say things we don't like (although IMO
those who don't want to hear them should not have to listen to them ...
but that's another topic and getting off the point of the simile). In a
similar way, programming can be hard when other programmers write
constructs we don't like. I agree that it's best for a language to help
programmers write readable and comprehensible programs - and even to
make them the easiest to write, if possible - but the very flexibility
which may allow them to do so may also give then the freedom to write
code we don't care for. I don't think one can legislate against that.

--
James Harris

On 08/11/2022 08:04, James Harris wrote:
> On 07/11/2022 17:53, Dmitry A. Kazakov wrote:
>> 1. Reduce number of precedence level to logical, additive,
>> multiplicative, highest order.

Many people expect "and" to bind more tightly than "or", so you
perhaps need [at least] two levels of logical. Somewhere between C and
hair shirts, there is perhaps some more sensible number?

>> 2. Require parenthesis for mixed operations at the same level
>> (except for * and /)

Don't know why the exception?

>> 3. No side effects of operators.

How is "side effect" defined for this purpose? But in any case
you can do this if only language-defined operators are allowed, but if
you want to allow users to [re-]define their own, it's much harder.
Once you've used languages with proper operators, you'll never want to
go back! Lots of things other than numbers can sensibly be added or
multiplied, even subtracted or divided.

> Good suggestions, especially ruling out operators with side effects. You
> wouldn't believe how much trouble they've been giving me.

You can get too paranoid about side-effects. They're like many
aspects of programming; they can be used for good or evil, and on the
whole you should let programmers use them that way. Good programmers
will use them wisely, bad programmers will write bad programs no matter
how hard you try to make them write good ones.

[...]
> I like the simplicity of the language which would result from your
> suggestions but can't help but think they would make programming in
> it less comfortable, like the simplicity of a hair shirt. ;)

If operator precedence and parentheses are a problem for you,
you could always switch to Polish [or Reverse Polish] notation. Also
solves the problem of operators that take three or more operands.

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

On 2022-11-08 16:13, Andy Walker wrote:
> On 08/11/2022 08:04, James Harris wrote:
>> On 07/11/2022 17:53, Dmitry A. Kazakov wrote:
>>> 1. Reduce number of precedence level to logical, additive,
>>> multiplicative, highest order.
>
>     Many people expect "and" to bind more tightly than "or", so you
> perhaps need [at least] two levels of logical.  Somewhere between C and
> hair shirts, there is perhaps some more sensible number?

There could be other operators like xor, implication etc.

>>> 2. Require parenthesis for mixed operations at the same level
>>> (except for * and /)
>
>     Don't know why the exception?

Because traditionally - and / do not require them. Actually the rule
should be: any same-valued non-associative operator need parenthesis:

a ^ b ^ c

is illegal (assuming ^ is exponentiation).

a + b + c

is OK.

>>> 3. No side effects of operators.
>
>     How is "side effect" defined for this purpose?

I would have a stated contract on a subprogram not to have side effects.
Only such subprograms may implement operators. One can partially enforce
this contract by checking calls statically. Should the programmer
violate the contract in some other way, the result would be a bounded
run-time error.

>     You can get too paranoid about side-effects.  They're like many
> aspects of programming;  they can be used for good or evil, and on the
> whole you should let programmers use them that way.  Good programmers
> will use them wisely, bad programmers will write bad programs no matter
> how hard you try to make them write good ones.

One could consider further contracts on actual arguments in order to
disallow expressions like:

Read + Read / Read

The general rule must be that evaluation order if not explicit must not
change the result (within the margins of rounding errors and exception
propagation). Though programmers would like to address exceptions too.

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

On 08/11/2022 13:43, Bart wrote:
> On 08/11/2022 08:33, David Brown wrote:
>> On 08/11/2022 01:15, Bart wrote:
>
>>> (Unless you go out of /your/ way to ensure it doesn't pass. But you'd
>>> be better off avoiding such code. There are a million ways of writing
>>> nonsense code that cannot be prohibited by a compiler.)
>>>
>>
>> Yes, because "gcc -Wall" is /so/ hard to write.
>
> And it's SO hard for a compiler to just use that as a default!

Yes, it /is/ hard to have it as the default. As I said, gcc is an
essential tool for vast amounts of software. You can't change the
behaviour of such a critical tool without massive consequences.

I would be very happy to see the warnings of -Wall, and more, as hard
errors by default in gcc. But it's not feasible - it will break endless
amount of code and build scripts, some of which has not been looked at
in decades. I have been supportive of moves in gcc towards better
defaults, but it is inevitably a very slow and limited process.

You are used to your own little world of your own tools, your own
language, your own code. Perhaps you don't realise what it means to
work with other people - certainly you don't understand what it means
for a language and a toolchain to be vital for /millions/ of programs.

When you start a /new/ tool, you get to make different decisions. You
get to learn from the past. You can enable a range of warnings by
default (and if it is a new language, rather than warnings you aim to
prohibit the poor code in the language rules). You can enable
optimisation by default in your new tool, so that halfwits will no
longer compile without optimisation and complain about the quality of
the code generation. You can make things like the choice of language
standard a mandatory option, so that people can't get it wrong. (Even
better, it should be mandatory in each code file.)

Of course, anyone who has a clue how to use a computer, cares about the
quality of the their coding, understands the need to learn about their
tools, can set up whatever scripts, makefiles, CFLAGS, batch files, or
other conveniences to get their particular preferences for compiler
flags simply and easily. That does mean you have to spend a few minutes
effort, and it means you no longer have an excuse for endless rants.
But I think most decent developers can manage it. Those that can't, or
won't, are likely to write shite code no matter what tools and languages
they are given because they simply don't care about what they are doing.

> So it
> stays safe for EVERYONE no matter how they invoke the compiler.
>
> Take a function like this which I consider much more dangerous than
> anything we've been discussing:
>
>    void fred() {}
>
> My bcc compiler gives a hard error: "() params are not allowed". But
> this works:

Listen carefully. No one gives a **** about your compiler. It's /your/
toy, just like your own language. If you like it, great. If you can
make a living from it, even better. But it does not compare to real
toolchains in any sense. You live in a different world here. You can
do /exactly/ what you like with your own tools, because they are for you
alone. Other toolchains and languages are not, and do not have the
luxury of the choices you can make.

The world runs on bad defaults - they are everywhere, in all aspects of
life and of society. We have them because they have been that way for
so long that it is impossible, or nearly impossible, to change them.
Often they were good choices when they were made, long ago. You can
sometimes make gradual changes, and you can make better choices for new
things, but you can't make big and sudden changes to things that lots of
people rely upon.

>
>    gcc c.c -c
>
> OK, I'll have to write -Wall as you say:
>
>    gcc -Wall c.c -c
>
> But, it still passes!

It is valid code - why would it not pass?

>
> (So much existing code wrongly uses () to mean no parameters - thanks no
> doubt to gcc's lax approach over decades - that I have to give bcc a
> special option to enable it when it comes up.)

No, existing C code uses () to mean unspecified number of parameters -
anything from zero upwards.

You claim to have made a C compiler - did you never actually look at the
language standards or learn the language?

Of course, since some people (myself included) see functions declared
with empty parentheses as poor style (it is, after all, obsolescent
since C99), gcc has an option to warn about it - "-Wstrict-prototypes".
But it is legal code in a form used by a lot of old code, and not
something you are likely to type accidentally, so it is not part of the
group "-Wall" of warnings that are mostly uncontroversial.

(In the next C standard, C23, "void foo()" will mean "foo" takes no
parameters, just like in C++.)

>
>>   I mean, it takes hours extra work, far out of your way.  Write
>> yourself a batch file with gcc flags - you could have done it 20 years
>> ago and saved yourself and everyone else enormous effort.
>
> Why do you expect people to have to themselves implement a chunk of the
> compiler they're using?
>

What? You complain that gcc's source is millions of lines long. How
does a few command-line options count as "a chunk of the compiler" ?

> And have to do so for every compiler - at one time I was using 7 or 8.
> ALL of them should be doing their jobs properly without being told.
>

They are. You just don't understand what their jobs are.

>
>
>> A major point of a good programming language - aided by good tools -
>> is to reduce the amount of bad code that is accepted.
>
> Yeah. In my language, A[i] only works when A is an array; P^ (pointer
> deref) only works when P is a pointer.
>
> Sounds obvious when put like that, but in C anything goes; Allowing A^
> and P[i] enables a huge amout of dangerous nonsense.
>

No, despite your continued exaggerations, C is not "anything goes". But
it /does/ allow some constructs that other languages don't (and vice versa).

You may not have noticed, in your eagerness to condemn everything C
related, including anyone who actually understands and uses the
language, that I have repeatedly recommend that the OP /not/ copy C in
his new language. The design decision for C's subscript to be syntactic
sugar for pointer dereferencing (you can't apply it to an array in C,
despite appearances that confuse you) made sense when C was created, and
for the expected uses of the language. That decision is no longer a
good choice for a modern language.

>
>>> I mean that you will not get any C compilers to get it to work: all
>>> report hard errors, and will not generate any code.
>>>
>>
>> So it is prohibited by the language.
>
> So is ++E + E++ prohibited by C or not? I'm none the wiser, but it
> sounds like, it depends!
>

Yes, it is prohibited by the language - as I said, and you bizarrely
claimed otherwise (saying "no actual need to prohibit in the language -
it just won't work"). It has nothing to do with types, it is in
language constraint clauses.

>
>>> It may be confusing to look at, but look at ANY C source and you will
>>> see complex expressions that are much harder to grok, like:
>>>
>>> OP(op,3f) { F = ((F&(SF|ZF|YF|XF|PF|CF))|((F&CF)<<4)|(A&(YF|XF)))^CF;
>>>           }
>>>
>>> (Is it even an expression? I /think/ it's function definition.)
>>
>> Are you arguing that because some people write C code that is even
>> harder to understand, the OP should allow these nonsense expressions
>> in his language?  That "logic" is like saying that because there are
>> bank robbers, people should be allowed to drunk-drive.
>
> YOU are arguing that you shouldn't be allowed to compose certain
> operators because the result might be confusing. But why single out
> these particular ones?

I didn't. You are making things up.

I recommend you take a step outside to your garden. Jump up and down
and scream "I hate C" at the top of your voice, until you are hoarse and
red in the face. Get it out your system. Then come back here, stop
posting ludicrous anti-C drivel, and maybe you can go back to
contributing usefully to the discussion. You have more experience in
home-made languages than most people - try to give useful advice and
leave anything about C to people who can talk about it rationally.

On 08/11/2022 14:24, James Harris wrote:
> On 07/11/2022 16:34, David Brown wrote:
>> On 07/11/2022 16:23, Bart wrote:

>>> The equivalent in C syntax for the first is:
>>>
>>>      ++*(P++);
>>>
>>> This compiles fine when P has type int* for example. It means this:
>>>
>>>    - Increment the pointe P
>>>    - Increment the location that P now points to (using the * deref op)
>>>
>>> So no reason to prohibit anything; it is perfectly well-defined.
>>
>> There is good reason to prohibit it - you got it wrong, so despite
>> being well-defined by the language, it is not clear code.
>>
>> The actual meaning of "++*(P++);" is :
>>
>>      1. Remember the original value of P - call it P_orig
>>      2. Increment P (that is, add sizeof(*P) to it).
>>      3. Increment the int at the location pointed to by P_orig.
>>      4. The value of the expression is the new updated value pointed
>> to by P_orig.
>
> That's a good example of how legitimate code can me made to look like
> gibberish by the evil programmer (tm). As I've mentioned elsewhere it's
> hard to invent rules to prohibit particular constructs simply because
> 'we don't like the look of them' and it would make the language harder
> to implement and understand if the language design included rules on
> 'aesthetics'.

You can't stop everything - those evil programmers have better
imaginations than any well-meaning language designer. But you can try.
Aim to make it harder to write convoluted code, and easier to write
clearer code. And try to make the clearer code more efficient, to
reduce the temptation to write evil code.

>
> It seems to have parallels with the free-speech debate. Free speech is
> easy when we get to choose what should be free and what should be banned
> - but then that's not free speech. In reality, free speech is hard
> because others may be free to say things we don't like (although IMO
> those who don't want to hear them should not have to listen to them ...
> but that's another topic and getting off the point of the simile).

There are /always/ limits on free speech. People don't always
understand that, but they exist. Failure to enforce appropriate limits
is as bad for society as failure to allow appropriate freedom of speech.
(But I agree that there is no easy answer as to where to draw the
lines, or who should be making or enforcing these limits.)

> In a
> similar way, programming can be hard when other programmers write
> constructs we don't like. I agree that it's best for a language to help
> programmers write readable and comprehensible programs - and even to
> make them the easiest to write, if possible - but the very flexibility
> which may allow them to do so may also give then the freedom to write
> code we don't care for. I don't think one can legislate against that.
>

I'm not sure it is the same - after all, if some one exercises their
rights to speak gibberish, or to give long, convoluted and
incomprehensible speaches, the listener has the right to go away, ignore
them, or fall asleep. It's harder for a compiler to do that!

On 07/11/2022 18:16, James Harris wrote:
> On 07/11/2022 14:23, Bart wrote:
>> On 07/11/2022 11:55, James Harris wrote:
>
> ..
>
>>>    ++E++
>>
>> This may not work, or not work as espected. The binding using my above
>> scheme means this is equivalent to ++(E++). But the second ++ requires
>> an lvalue as input, and yields an rvalue, which would be an invalid
>> input to the first ++.
>
> Yes. If
>
>   ++E++
>
> is going to be permitted

Then you need to define what it means. Here, suppose that in each case E
starts off as 100:

E++ # What value does E have afterwards?

++E # What value does E have afterwards?

X := E++ # What is the value of X?

++E++ # What is the value of E after?

X := ++E++ # What is the value of X? What is the type and value
# of the E++ portion?

I can't make ++E++ work in any of my languages because of type/lvalue
discrepancies.

then for programmer sanity wouldn't it be true
> to say that both ++ operators need to refer to the same lvalue? If so then
>
>   ++p
>
> should probably have higher precedence than
>
>   p++
>
> or perhaps their precedences could be the same but they be applied in
> left-to-right order.

It would already be a big deal, and a vast improvement over C, that "^"
is a postfix op; don't push it!

> It may be worth looking at other operators which take in AND produce
> lvalues, most familiarly array indexing and field referencing, and hence
> they can be incremented. Isn't it true that for both ++ operators of
>
>   ++points.x[1]
>   points.x[1]++
>
> that a programmer would normally want points.x[1] incremented, i.e.
> field referencing and array indexing would take precedence over either
> ++ operator?

I'm not sure what you're asking here or where producing lvalues comes in
to it. Those examples work as expected in my language:

record R =
var x
end

points:=R((10,20,30))
println points # (10, 20, 30)

++points.x[1]
println points # (11, 20, 30)

points.x[1]++
println points # (12, 20, 30)

However, my syntax works a specific way:

* "." is not considered a normal binary operator (because it isn't).

* "[]" is not considered that either (this is more typical)

So `points.x[1]` forms a single expression term. Unary ops like `++`
work on a term. If "." was a normal binary op, then your example would
be parsed as:

(++points).x[1]

unless you make special rules just for ++.

Note, usually ++A and A++ are interchangeable. There is only different
behaviour if you try to use the resulting value (the first then returns
new A, the second returns old A).

> But now what about dereference? Should it also take precedence over the
> ++ operators or should it come after one or both? For instance, what
> should the following mean?
>
>   ++p^
>
> Should it be
>
>   (++p)^
>
> or
>
>   ++(p^)

Isn't it just up to unary op evaluation? I already said how it's
typically done, so that ++p^ means ++(p^). If it's unclear, then just
use parentheses.

On 08/11/2022 16:20, David Brown wrote:
> On 08/11/2022 13:43, Bart wrote:
>> On 08/11/2022 08:33, David Brown wrote:
>>> On 08/11/2022 01:15, Bart wrote:
>>
>>>> (Unless you go out of /your/ way to ensure it doesn't pass. But
>>>> you'd be better off avoiding such code. There are a million ways of
>>>> writing nonsense code that cannot be prohibited by a compiler.)
>>>>
>>>
>>> Yes, because "gcc -Wall" is /so/ hard to write.
>>
>> And it's SO hard for a compiler to just use that as a default!
>
> Yes, it /is/ hard to have it as the default.

No it isn't. And the consequences of allowing terrible, error prone
legacy code are considerable.

You need ONE new option in a compiler, example:

gcc --classic

(Or, more apt, --unsafe.)

That means that the next generation of lazy and/or newbie C programmers
who don't bother with options get used to a stricter and safer version
of the language.

> But it's not feasible - it will break endless
> amount of code and build scripts,

They are likely to break anyway - don't you say that you archive
complete compilers to ensure your projects can always be built?

> You are used to your own little world of your own tools, your own
> language, your own code.  Perhaps you don't realise what it means to
> work with other people - certainly you don't understand what it means
> for a language and a toolchain to be vital for /millions/ of programs.

Here we are designing new languages and new tools. They don't
necessarily need to be for the mass market.

>>
>>     gcc c.c -c
>>
>> OK, I'll have to write -Wall as you say:
>>
>>     gcc -Wall c.c -c
>>
>> But, it still passes!
>
> It is valid code - why would it not pass?

Because it's fucking stupid code:

#include <stdio.h>

int fred() {return 0;}

int main(void) {
fred(1,2,3,4,5,6,7,8,9,10);
fred("Hello, World!");
fred(fred,fred,fred(fred(fred)));
}

On what planet could all those calls to fred() be correct? All of them,
except at most one, will be wrong. And dangerous.

Yet 'gcc -Wall -Wextra -Wpedantic etc etc` passes it quite happily.

That is a fucking stupid compiler.

>>
>> (So much existing code wrongly uses () to mean no parameters - thanks
>> no doubt to gcc's lax approach over decades - that I have to give bcc
>> a special option to enable it when it comes up.)
>
> No, existing C code uses () to mean unspecified number of parameters -
> anything from zero upwards.

No, all the C code I've seen routinely uses () to mean zero parameters
only. The problem with that is that any number of parameters of any
types can be passed, clearly incorrectly, and it cannot be detected.

Code that uses () correctly (normally associated with function pointers)
needs to ensure that the call and the callee match in argument counts
and types. That's why it is dangerous. But this use is unusual.

(In my language, that is achieved with explicit function pointer casts.)

> You claim to have made a C compiler - did you never actually look at the
> language standards or learn the language?

I made a compiler for a subset of C - minus some features. () parameters
need to be enabled by a legacy switch like the one I mentioned, in my
case called '-old'.

> (In the next C standard, C23, "void foo()" will mean "foo" takes no
> parameters, just like in C++.)

Will my nonsense program still pass?

>>
>>>   I mean, it takes hours extra work, far out of your way.  Write
>>> yourself a batch file with gcc flags - you could have done it 20
>>> years ago and saved yourself and everyone else enormous effort.
>>
>> Why do you expect people to have to themselves implement a chunk of
>> the compiler they're using?
>>
>
> What?  You complain that gcc's source is millions of lines long.  How
> does a few command-line options count as "a chunk of the compiler" ?

By using 1000s of options to control every aspect of the process. The
options form a mini-DSL to build a custom dialect of a language.

> No, despite your continued exaggerations, C is not "anything goes".  But
> it /does/ allow some constructs that other languages don't (and vice
> versa).
>
> You may not have noticed, in your eagerness to condemn everything C
> related, including anyone who actually understands and uses the
> language, that I have repeatedly recommend that the OP /not/ copy C in
> his new language.  The design decision for C's subscript to be syntactic
> sugar for pointer dereferencing (you can't apply it to an array in C,
> despite appearances that confuse you)

You mean appearances like this:

int A[10];
int x;

x = *A;

gcc is happy with this.

>> So is ++E + E++ prohibited by C or not? I'm none the wiser, but it
>> sounds like, it depends!
>>
>
> Yes, it is prohibited by the language

Yet no compiler stopped me creating an executable. So why is ++E++ a
hard error and not ++E + E++?

> - as I said, and you bizarrely
> claimed otherwise (saying "no actual need to prohibit in the language -
> it just won't work").

Yes, about ++E++. Not ++E + E++; I merely observed that gcc didn't take
the latter seriously.

>  It has nothing to do with types, it is in
> language constraint clauses.
>
>>
>>>> It may be confusing to look at, but look at ANY C source and you
>>>> will see complex expressions that are much harder to grok, like:
>>>>
>>>> OP(op,3f) { F =
>>>> ((F&(SF|ZF|YF|XF|PF|CF))|((F&CF)<<4)|(A&(YF|XF)))^CF;           }
>>>>
>>>> (Is it even an expression? I /think/ it's function definition.)
>>>
>>> Are you arguing that because some people write C code that is even
>>> harder to understand, the OP should allow these nonsense expressions
>>> in his language?  That "logic" is like saying that because there are
>>> bank robbers, people should be allowed to drunk-drive.
>>
>> YOU are arguing that you shouldn't be allowed to compose certain
>> operators because the result might be confusing. But why single out
>> these particular ones?
>
> I didn't.  You are making things up.

You said:

> Make it a syntax error.

about ++E++^ and ++E^++. Before going on to compare that syntax with
Brainfuck.

>
> I recommend you take a step outside to your garden.  Jump up and down
> and scream "I hate C" at the top of your voice, until you are hoarse and
> red in the face.  Get it out your system.

I suggest you do the same with "I hate Bart".

I already know that the stuff I do is miles better than C, while still
being simple, low-level, small footprint and easy to build fast. Thanks
for reminding me what a quagmire it is.

> Then come back here, stop
> posting ludicrous anti-C drivel, and maybe you can go back to
> contributing usefully to the discussion.  You have more experience in
> home-made languages than most people - try to give useful advice and
> leave anything about C to people who can talk about it rationally.

This is not the C group. C comes up tangentially from time to time. But
I believe it was mostly you who wholesale dragged C and its compilers
into the discussion.

Please do not reply to this. I'm not interested in taking it any further.

On 2022-11-08 18:46, Bart wrote:

> No it isn't. And the consequences of allowing terrible, error prone
> legacy code are considerable.

Wrong. Backward compatibility trumps everything, absolutely everything.
Legacy C, FORTRAN, COBOL code is far more stable than whatever new garbage.

Unless your new language supports strong typing, contracts and formal
verification, I'd better take old C code, than newly introduced fancy bugs.

From a new language I expect new technological level. So long you guys
are keeping on reinventing C, I'd better stay with C.

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

On 08/11/2022 18:18, Dmitry A. Kazakov wrote:
> On 2022-11-08 18:46, Bart wrote:
>
>> No it isn't. And the consequences of allowing terrible, error prone
>> legacy code are considerable.
>
> Wrong. Backward compatibility trumps everything, absolutely everything.
> Legacy C, FORTRAN, COBOL code is far more stable than whatever new garbage.
>
> Unless your new language supports strong typing, contracts and formal
> verification, I'd better take old C code, than newly introduced fancy bugs.
>
> From a new language I expect new technological level. So long you guys
> are keeping on reinventing C, I'd better stay with C.
>
They are plenty of newer, more ground-breaking languages around that
might suit you: Rust, Zig, Odin, Dart, Julia... Or functional ones like
Haskell, OCaml, F#.

The ones I create are for personal use and occupy a particular niche in
the range of possible languages. They are roughly represented by M and Q
along this line:

C--M-----Q-----------Python

My codebase is small so backward compatibility (with my own languages)
is not a great priority. I'm doing some innovative stuff with how the
compilers work and how projects are managed and run, but the feature set
of the languages themselves is not advanced, and actually less important.

You yourself said to keep the set of operations minimal. I'm doing that
with the features I have no interest in, such as over-strict type systems.

On 08/11/2022 18:46, Bart wrote:
> On 08/11/2022 16:20, David Brown wrote:
>> On 08/11/2022 13:43, Bart wrote:
>>> On 08/11/2022 08:33, David Brown wrote:
>>>> On 08/11/2022 01:15, Bart wrote:
>>>
>>>>> (Unless you go out of /your/ way to ensure it doesn't pass. But
>>>>> you'd be better off avoiding such code. There are a million ways of
>>>>> writing nonsense code that cannot be prohibited by a compiler.)
>>>>>
>>>>
>>>> Yes, because "gcc -Wall" is /so/ hard to write.
>>>
>>> And it's SO hard for a compiler to just use that as a default!
>>
>> Yes, it /is/ hard to have it as the default.
>
> No it isn't. And the consequences of allowing terrible, error prone
> legacy code are considerable.
>
> You need ONE new option in a compiler, example:
>
>    gcc --classic
>
> (Or, more apt, --unsafe.)

That would be one way to break all existing build systems.

It really is quite simple.

(Note that I /agree/ with you entirely that it would be /better/ if gcc
was far stricter by default. I am trying to explain to you why it cannot.)

Also remember that gcc plays two significantly different roles. In one
case, it is a development tool - you use it with appropriate warnings
and flags (and other tools, such as debuggers and profilers) to help
write correct code. Here warnings are vital feedback to the developer.

The other role is as a systems compiler. This is not a concept familiar
to Windows users, but in the *nix world (and most other OS's) software
is often distributed as source. The source is, at least in theory,
known to be correct - so the compiler should be as quiet as practically
possible. The assumption is that any warnings that might be given are
false positives. That has to be the default setting for compiler options.

>
>>>
>>>     gcc c.c -c
>>>
>>> OK, I'll have to write -Wall as you say:
>>>
>>>     gcc -Wall c.c -c
>>>
>>> But, it still passes!
>>
>> It is valid code - why would it not pass?
>
> Because it's fucking stupid code:

I agree. But it is valid C code, so any C compiler has to accept it.

>
>     #include <stdio.h>
>
>     int fred() {return 0;}
>
>     int main(void) {
>         fred(1,2,3,4,5,6,7,8,9,10);
>         fred("Hello, World!");
>         fred(fred,fred,fred(fred(fred)));
>     }
>
> On what planet could all those calls to fred() be correct? All of them,
> except at most one, will be wrong. And dangerous.

Now you have code that /is/ undefined behaviour. And a good enough
compiler /could/ spot that and reject it. Unfortunately, it is often
very hard to do in real-life cases, and there is little point in making
the effort to deal with pathological artificial cases.

gcc has warnings that will complain about this code. It would have been
better if these were enabled by default, or at least in -Wall.

>
> Yet 'gcc -Wall -Wextra -Wpedantic etc etc` passes it quite happily.
>
> That is a fucking stupid compiler.
>

It is a compiler that values backwards compatibility above usability,
for a language that puts backwards compatibility above new features or
improvements to the language. Both the language and the toolchain
expect users to take responsibility of their code and their use of their
tools.

When I program in C, using gcc, the above code would be marked as an
error. If I can do it, so can you. It would be nice if it were easier
or more automatic, but that's how it goes.

>
>>>
>>> (So much existing code wrongly uses () to mean no parameters - thanks
>>> no doubt to gcc's lax approach over decades - that I have to give bcc
>>> a special option to enable it when it comes up.)
>>
>> No, existing C code uses () to mean unspecified number of parameters -
>> anything from zero upwards.
>
> No, all the C code I've seen routinely uses () to mean zero parameters
> only.

Existing code uses it to mean an unspecified number of parameters,
anything from zero upwards.

It's very likely that meaning /zero/ parameters is the most common usage
(especially since that's what it means in C++, and what it will mean in
C23). But it is not the only usage. In particular, it can be a K&R
style declaration of an external function, regardless of the number of
parameters. There is still K&R C code in use today - and there are
still some people who write their C in K&R style (perhaps because some
people think "The C Programming Language" is a good way to learn the
language).

> The problem with that is that any number of parameters of any
> types can be passed, clearly incorrectly, and it cannot be detected.
>

Yes. That's why function prototypes were added to the language in C90.
But non-prototype declarations could not be removed.

> Code that uses () correctly (normally associated with function pointers)
> needs to ensure that the call and the callee match in argument counts
> and types. That's why it is dangerous. But this use is unusual.

What do you mean? There is no non-obsolescent use of "()" in
declarations of functions, types, pointers, or anything else. It exists
only as a backwards compatibility feature for K&R style non-prototype
function declarations. And of course you can /call/ a function with no
parameters as "foo()", either by function name or via a
pointer-to-function-with-no-parameters. When you use prototype function
declarations, the compiler can check that the call and callee match in
argument counts and types (assuming you use the same declarations in
each source file).

>
> (In my language, that is achieved with explicit function pointer casts.)
>

If you have function pointer casts, your risk of error is high and you
need to checking things manually. The same applies in C - there are no
implicit casts of function pointer types.

>
>> You claim to have made a C compiler - did you never actually look at
>> the language standards or learn the language?
>
>
> I made a compiler for a subset of C - minus some features. () parameters
> need to be enabled by a legacy switch like the one I mentioned, in my
> case called '-old'.
>

If it is just a subset of C, with no attempt at conformity, then it is
misleading to refer to it as a C compiler. (It can still be a useful
tool for your own use.)

>> (In the next C standard, C23, "void foo()" will mean "foo" takes no
>> parameters, just like in C++.)
>
> Will my nonsense program still pass?
>

No. It would be as though you had written "int fred(void) {return 0;}"
as the first line.

>>>
>>>>   I mean, it takes hours extra work, far out of your way.  Write
>>>> yourself a batch file with gcc flags - you could have done it 20
>>>> years ago and saved yourself and everyone else enormous effort.
>>>
>>> Why do you expect people to have to themselves implement a chunk of
>>> the compiler they're using?
>>>
>>
>> What?  You complain that gcc's source is millions of lines long.  How
>> does a few command-line options count as "a chunk of the compiler" ?
>
> By using 1000s of options to control every aspect of the process. The
> options form a mini-DSL to build a custom dialect of a language.
>

Most people don't need more than a few options, you cannot control
"every aspect", it is not a DSL and you are not making a "custom
dialect". That is all wild exaggeration. For most programmers, and
most uses, "-Wall -std=c11 -O2" will cover the basics. My work is more
specialised, and I regularly need a fair number of extra flags (such as
specifying details of the target processor, linking setup, etc.). I
also like to have paranoid levels of warnings and some weird
optimisation flags - but I am quite unusual in that respect.

>> No, despite your continued exaggerations, C is not "anything goes".
>> But it /does/ allow some constructs that other languages don't (and
>> vice versa).
>>
>> You may not have noticed, in your eagerness to condemn everything C
>> related, including anyone who actually understands and uses the
>> language, that I have repeatedly recommend that the OP /not/ copy C in
>> his new language.  The design decision for C's subscript to be
>> syntactic sugar for pointer dereferencing (you can't apply it to an
>> array in C, despite appearances that confuse you)
>
> You mean appearances like this:
>
>     int A[10];
>     int x;
>
>     x = *A;
>
> gcc is happy with this.

On 08/11/2022 20:15, Bart wrote:
> On 08/11/2022 18:18, Dmitry A. Kazakov wrote:
>> On 2022-11-08 18:46, Bart wrote:
>>
>>> No it isn't. And the consequences of allowing terrible, error prone
>>> legacy code are considerable.
>>
>> Wrong. Backward compatibility trumps everything, absolutely
>> everything. Legacy C, FORTRAN, COBOL code is far more stable than
>> whatever new garbage.
>>
>> Unless your new language supports strong typing, contracts and formal
>> verification, I'd better take old C code, than newly introduced fancy
>> bugs.
>>
>>  From a new language I expect new technological level. So long you
>> guys are keeping on reinventing C, I'd better stay with C.
>>
> They are plenty of newer, more ground-breaking languages around that
> might suit you: Rust, Zig, Odin, Dart, Julia... Or functional ones like
> Haskell, OCaml, F#.
>

Most of these are something very different from C. Haskell and OCaml
are, as you say, functional programming languages and a totally
different concept. (They are a lot of fun and highly educational.) I
don't know if anyone actually uses F# - it always struck me as another
Microsoft me-too language, like C# but without the market popularity.

Dart is dead, AFAIK, showing the risks of picking a new language. Zig
is arguably a low-level C alternative, except it too is barely used.
Odin is - well, you know it is not a mainstream choice when it doesn't
even have a Wikipedia page. And Julia has its fans for particular uses,
which do not overlap much with the kind of task you'd do in C.

Which leaves Rust as the only new serious alternative to C these days
(along with C++). Rust has its pros and cons, but is definitely worth
considering. Certainly any budding low-level language designer should
learn it and play with it, to see which features they want to copy and
which to drop. One of the nice things about Rust is that the add-on
tools for resource tracking are inspiring better analysis tools for C
and C++ - such rivalry is often useful.

On 08/11/2022 20:28, David Brown wrote:
> On 08/11/2022 18:46, Bart wrote:

>> I made a compiler for a subset of C - minus some features. ()
>> parameters need to be enabled by a legacy switch like the one I
>> mentioned, in my case called '-old'.
>>
>
> If it is just a subset of C, with no attempt at conformity, then it is
> misleading to refer to it as a C compiler.  (It can still be a useful
> tool for your own use.)

There must be 1000s of amateur C compiler projects, probably more than
for any other language.

Mine was able to build programs like Lua, Tiny C, Seed7 and SQLite, and
run those programs to varying degrees. So more capable than most, but I
usually refer to it in docs as a C-subset compiler.

Whatever C coding I do these days will be in that subset, and mine will
be my first choice of C compiler. Any machine-generated C will be in
that same subset.

>>> (In the next C standard, C23, "void foo()" will mean "foo" takes no
>>> parameters, just like in C++.)
>>
>> Will my nonsense program still pass?
>>
>
> No.  It would be as though you had written "int fred(void) {return 0;}"
> as the first line.

So what happened to backwards compatibility? All those programs which
call () functions with more arguments will no longer work.

On 09/11/2022 00:06, Bart wrote:
> On 08/11/2022 20:28, David Brown wrote:
>> On 08/11/2022 18:46, Bart wrote:
>
>>> I made a compiler for a subset of C - minus some features. ()
>>> parameters need to be enabled by a legacy switch like the one I
>>> mentioned, in my case called '-old'.
>>>
>>
>> If it is just a subset of C, with no attempt at conformity, then it is
>> misleading to refer to it as a C compiler.  (It can still be a useful
>> tool for your own use.)
>
> There must be 1000s of amateur C compiler projects, probably more than
> for any other language.
>
> Mine was able to build programs like Lua, Tiny C, Seed7 and SQLite, and
> run those programs to varying degrees. So more capable than most, but I
> usually refer to it in docs as a C-subset compiler.

OK.

>
> Whatever C coding I do these days will be in that subset, and mine will
> be my first choice of C compiler. Any machine-generated C will be in
> that same subset.
>

Almost everyone in practice uses a subset of the language in choice. If
you are releasing a compiler for general use, you have to support
everything (even monstrosities like "longjmp"), but for your own use (or
for specialised use, such as tied to a transcompiler for a different
language), you only need the features you will use yourself.

>
>>>> (In the next C standard, C23, "void foo()" will mean "foo" takes no
>>>> parameters, just like in C++.)
>>>
>>> Will my nonsense program still pass?
>>>
>>
>> No.  It would be as though you had written "int fred(void) {return
>> 0;}" as the first line.
>
> So what happened to backwards compatibility? All those programs which
> call () functions with more arguments will no longer work.
>

I still don't understand what you mean.

int (*f)(void);
int (*g)(int, int);

void foo(void) {
f(); // Good
g(1, 2); // Good
f(1, 2); // Error
g(); // Error
}

Function pointers of different types - that is, different return types,
different numbers or types of parameters - are incompatible in C. There
are no implicit convertions between them (unlike objects pointers and
void*), there is no common base type, and any use of explicit casts will
lead to undefined behaviour if you don't cast back to the right type
before calling the function. Even the cast back and forth is
implementation dependent - an implementation could use different sizes
for different function pointer types.

In practice, of course, most implementations have the same size of
pointer for all function types. On some real-world targets it will be
different from the size of object pointers (imagine a 16-bit system with
"large" code model and "small" data model, or vice versa). But C still
does not allow you to mess with the function pointer types without
explicit "I know what I am doing" casts.

On 09/11/2022 08:12, David Brown wrote:
> On 09/11/2022 00:06, Bart wrote:

>> So what happened to backwards compatibility? All those programs which
>> call () functions with more arguments will no longer work.
>>
>
> I still don't understand what you mean.
>
> int (*f)(void);
> int (*g)(int, int);
>
> void foo(void) {
>     f();        // Good
>     g(1, 2);        // Good
>     f(1, 2);        // Error
>     g();        // Error
> }
>
> Function pointers of different types - that is, different return types,
> different numbers or types of parameters - are incompatible in C.  There
> are no implicit convertions between them (unlike objects pointers and
> void*), there is no common base type, and any use of explicit casts will
> lead to undefined behaviour if you don't cast back to the right type
> before calling the function.  Even the cast back and forth is
> implementation dependent - an implementation could use different sizes
> for different function pointer types.
>
> In practice, of course, most implementations have the same size of
> pointer for all function types.  On some real-world targets it will be
> different from the size of object pointers (imagine a 16-bit system with
> "large" code model and "small" data model, or vice versa).  But C still
> does not allow you to mess with the function pointer types without
> explicit "I know what I am doing" casts.

The following code is a legitimate use of () parameter lists:

#include <stdio.h>

int f1(int a) {return a;}
int f2(int a, int b) {return a+b;}
int f3(int a, int b, int c) {return a+b+c;}

int (*fntable[])() = {NULL, f3, f1, f2};
int args[] = {0, 3, 1, 2};

int main(void) {
int n =3, x;

switch (args[n]) {
case 1: x=fntable[n](10); break;
case 2: x=fntable[n](20,30); break;
case 3: x=fntable[n](40,50,60); break;
}

printf("x=%d\n",x);
}

'fntable' is populated with functions of mixed signatures. When calling
one of those functions, the user-code must ensure the function pointer
is called with the right arguments for that specific function.

That is done here with the switch statement. If the () in this line:

int (*fntable[])() = {NULL, f3, f1, f2};

is assumed to be (void) in C23, then initialising with f1, f2, f3 will
be illegal, and all those calls will be too. This is why I said, what
happened to backwards compatibility.

In my language there is no equivalent to C's unchecked () parameter
list. There I would likely use the equivalent of void* pointers and
apply a cast at the point of call. The same could be done in C.

On Tuesday, 8 November 2022 at 16:42:36 UTC, Bart wrote:
> On 07/11/2022 18:16, James Harris wrote:
> > On 07/11/2022 14:23, Bart wrote:
> >> On 07/11/2022 11:55, James Harris wrote:
> >
> > ..
> >
> >>> ++E++
> >>
> >> This may not work, or not work as espected. The binding using my above
> >> scheme means this is equivalent to ++(E++). But the second ++ requires
> >> an lvalue as input, and yields an rvalue, which would be an invalid
> >> input to the first ++.
> >
> > Yes. If
> >
> > ++E++
> >
> > is going to be permitted
> Then you need to define what it means.

Indeed. Given the relative precedences mentioned in another reply I'd have the operations in this order:

prefix ++
postfix ++

Replies below based on that order (although I gather you have the opposite order).

>
> Here, suppose that in each case E
> starts off as 100:
>
> E++ # What value does E have afterwards?

101

>
> ++E # What value does E have afterwards?

Also 101

>
> X := E++ # What is the value of X?

100

>
> ++E++ # What is the value of E after?

102

(++E)++

>
> X := ++E++ # What is the value of X? What is the type and value
> # of the E++ portion?

X: 101
(E would still end up holding 102)
As a subexpression it would have the type and the intermediate value of E (101), not of E++. The trailing ++ would not contribute to the value of the subexpression; it would serve only to alter the stored value after the intermediate value of 101 had flown the nest..

X := ((++E)++)

>
> I can't make ++E++ work in any of my languages because of type/lvalue
> discrepancies.

Is that because you evaluate postfix ++ first?

> then for programmer sanity wouldn't it be true
> > to say that both ++ operators need to refer to the same lvalue? If so then
> >
> > ++p
> >
> > should probably have higher precedence than
> >
> > p++
> >
> > or perhaps their precedences could be the same but they be applied in
> > left-to-right order.
> It would already be a big deal, and a vast improvement over C, that "^"
> is a postfix op; don't push it!

:)

> > It may be worth looking at other operators which take in AND produce
> > lvalues, most familiarly array indexing and field referencing, and hence
> > they can be incremented. Isn't it true that for both ++ operators of
> >
> > ++points.x[1]
> > points.x[1]++
> >
> > that a programmer would normally want points.x[1] incremented, i.e.
> > field referencing and array indexing would take precedence over either
> > ++ operator?
> I'm not sure what you're asking here or where producing lvalues comes in
> to it.
> Those examples work as expected in my language:
>
> record R =
> var x
> end
>
> points:=R((10,20,30))
> println points # (10, 20, 30)
>
> ++points.x[1]
> println points # (11, 20, 30)
>
> points.x[1]++
> println points # (12, 20, 30)
>
> However, my syntax works a specific way:
>
> * "." is not considered a normal binary operator (because it isn't).
>
> * "[]" is not considered that either (this is more typical)
>
> So `points.x[1]` forms a single expression term. Unary ops like `++`
> work on a term. If "." was a normal binary op, then your example would
> be parsed as:
>
> (++points).x[1]
>
> unless you make special rules just for ++.

I have "." and "[....]" as normal operators but of high precedence. They are prioritised before the others we have been talking about. Either way the effect is the same.

>
> Note, usually ++A and A++ are interchangeable. There is only different
> behaviour if you try to use the resulting value (the first then returns
> new A, the second returns old A).
> > But now what about dereference? Should it also take precedence over the
> > ++ operators or should it come after one or both? For instance, what
> > should the following mean?
> >
> > ++p^
> >
> > Should it be
> >
> > (++p)^
> >
> > or
> >
> > ++(p^)
> Isn't it just up to unary op evaluation? I already said how it's
> typically done, so that ++p^ means ++(p^). If it's unclear, then just
> use parentheses.

Yes, it's up to unary op evaluation order. As a result of this discussion I have gone for **E before E** before E^ and would evaluate the above as

(++p)^

--
James

On 09/11/2022 12:24, Bart wrote:
> On 09/11/2022 08:12, David Brown wrote:
>> On 09/11/2022 00:06, Bart wrote:
>
>>> So what happened to backwards compatibility? All those programs which
>>> call () functions with more arguments will no longer work.
>>>
>>
>> I still don't understand what you mean.
>>
>> int (*f)(void);
>> int (*g)(int, int);
>>
>> void foo(void) {
>>      f();        // Good
>>      g(1, 2);        // Good
>>      f(1, 2);        // Error
>>      g();        // Error
>> }
>>
>> Function pointers of different types - that is, different return
>> types, different numbers or types of parameters - are incompatible in
>> C.  There are no implicit convertions between them (unlike objects
>> pointers and void*), there is no common base type, and any use of
>> explicit casts will lead to undefined behaviour if you don't cast back
>> to the right type before calling the function.  Even the cast back and
>> forth is implementation dependent - an implementation could use
>> different sizes for different function pointer types.
>>
>> In practice, of course, most implementations have the same size of
>> pointer for all function types.  On some real-world targets it will be
>> different from the size of object pointers (imagine a 16-bit system
>> with "large" code model and "small" data model, or vice versa).  But C
>> still does not allow you to mess with the function pointer types
>> without explicit "I know what I am doing" casts.
>
> The following code is a legitimate use of () parameter lists:
>
>     #include <stdio.h>
>
>     int f1(int a) {return a;}
>     int f2(int a, int b) {return a+b;}
>     int f3(int a, int b, int c) {return a+b+c;}
>
>     int (*fntable[])() = {NULL, f3, f1, f2};

That is using a K&R style non-prototyped function types.

>     int args[] = {0, 3, 1, 2};
>
>     int main(void) {
>         int n =3, x;
>
>         switch (args[n]) {
>         case 1: x=fntable[n](10); break;
>         case 2: x=fntable[n](20,30); break;
>         case 3: x=fntable[n](40,50,60); break;
>         }
>
>         printf("x=%d\n",x);
>     }
>
> 'fntable' is populated with functions of mixed signatures. When calling
> one of those functions, the user-code must ensure the function pointer
> is called with the right arguments for that specific function.
>
> That is done here with the switch statement. If the () in this line:
>
>     int (*fntable[])() = {NULL, f3, f1, f2};
>
> is assumed to be (void) in C23, then initialising with f1, f2, f3 will
> be illegal, and all those calls will be too. This is why I said, what
> happened to backwards compatibility.

Yes, this could be a problem, and is an interesting example.

I must admit I did not realise that pointers to "old-style" function
type pointers are considered compatible to any function type pointer
with the same return type - that was new to me. Old-style (K&R)
function declarations have been obsolescent since C89/C90, and it is a
source of annoyance to me that such obsolescent features have been
allowed to remain in the language for /so/ long.

I can appreciate that using "int (*)()" is convenient here because it
avoids the need for casts. I would personally include the casts - using
typedefs for clarity - because calling via old-style function types is
more limited. If one of your functions has a parameter of type "float",
an integer type smaller than "int", _Bool, or a character type, then the
behaviour is undefined.

>
> In my language there is no equivalent to C's unchecked () parameter
> list. There I would likely use the equivalent of void* pointers and
> apply a cast at the point of call. The same could be done in C.

Yes, though you would want to use "void (*)(void)" pointers in C, rather
than "void *" pointers - function pointers and object pointers are very
different beasts.

I'm glad to see that you don't have an equivalent C's long-outdated
unchecked function types. And I'm glad it is being dropped in C23.
(clang has warned about it by default for a while, and gcc is
considering doing so - but wary due to compatibility with existing
builds. I expect they will run a trial "rebuild everything in Debian
and see if anything breaks" before deciding.)

I would recommend that in your own code generator, you use "void
(*)(void)" pointers and put in the casts in the generated C code. If
they are already present in the source Bart-language files, it should
not be difficult.

Then you could add a hard error on any use of K&R declarations to your C
compiler, and score a point over gcc :-)

On 09/11/2022 13:53, James Harris wrote:
> On Tuesday, 8 November 2022 at 16:42:36 UTC, Bart wrote:

>> ++E++ # What is the value of E after?
>
> 102
>
> (++E)++
>
>>
>> X := ++E++ # What is the value of X? What is the type and value
>> # of the E++ portion?
>
> X: 101
> (E would still end up holding 102)

> As a subexpression it would have the type and the intermediate value of E (101), not of E++.

This is where your approach differs from mine. It sounds like you would
also allow this:

++ ++ ++ E

so that E becomes 103? It doesn't then matter whether ++ is prefix or
postfix. If that isn't the case (yours only works with mixed
prefix/postfix), then I can only explain it like this:

++E is the same as: (E:=E+1; E) # that final E is an lvalue

E++ is the same as: (T:=E; E:=E+1; T)

the final T /is/ an lvalue, but not the right one! You can't use it to
modify E.

That wouldn't work for me anyway because T is a transient value
(typically stored on the stack, register or unaccessible temporary -
it's got to exist somewhere!) with no lvalue. It's similar to this:

A+B is the same as: (T:=A+B; T)

It's clear that ++(A+B) can't work unless you change what ++ means (eg.
++A now means (A+1) because whatever ++ modifies is not accessible).

If that's how your approach works, then it would be unorthogonal:

++(E++) works
(++E)++ doesn't

even though you'd expect E to be 102 in both cases (and to deliver 101
in both cases too). And:

++ ++ E works
E ++ ++ doesn't

On 07/11/2022 16:16, Dmitry A. Kazakov wrote:
> On 2022-11-07 16:06, Bart wrote:
>> On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
>>> On 2022-11-07 13:52, James Harris wrote:
>>>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>>>> On 2022-11-07 12:55, James Harris wrote:
>>>>>
>>>>>>    ++E + E++
>>>>>>    ++E++
>>>>>>    V = V++

....

> ++ means cheap keyboard with broken keys or coffee spilled over it... (:-))

A bit like Ada's --, then. ;-)

--
James Harris

On 2022-11-13 16:54, James Harris wrote:
> On 07/11/2022 16:16, Dmitry A. Kazakov wrote:

>> ++ means cheap keyboard with broken keys or coffee spilled over it...
>> (:-))
>
> A bit like Ada's --, then. ;-)

In Ada -- is a comment, not operator.

An interesting question regarding operator's symbol is: sticking to
ASCII or going Unicode. Let's say we wanted an increment operator (I do
not). Why ++ from 60's? Take the increment (∆) or the upwards arrow ↑ etc.

Note that all arguments against Unicode apply to operators. If the thing
is difficult to type then it is difficult to remember: precedence level,
associativity, semantics. If you can hold these in your head, you could
remember the key combination as well. If you do not, then, maybe, having
a subprogram Increment() would be better choice?

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

On 10/11/2022 10:42, Bart wrote:
> On 09/11/2022 13:53, James Harris wrote:
>> On Tuesday, 8 November 2022 at 16:42:36 UTC, Bart wrote:
>
>>> ++E++ # What is the value of E after?
>>
>> 102
>>
>> (++E)++
>>
>>>
>>> X := ++E++ # What is the value of X? What is the type and value
>>> # of the E++ portion?
>>
>> X: 101
>> (E would still end up holding 102)
>
>> As a subexpression it would have the type and the intermediate value
>> of E (101), not of E++.
>
> This is where your approach differs from mine. It sounds like you would
> also allow this:
>
>     ++ ++ ++ E
>
> so that E becomes 103?

That sounds right. Prefix operators have naturally to be applied right
to left.

It looks, by the way, almost as mad as a programmer writing

E = E + 1 + 1 + 1

> It doesn't then matter whether ++ is prefix or
> postfix.

I don't follow. In general (e.g. if autoincrement were to be used in an
expression) then it /would/ matter whether prefix or postfix were used.

> If that isn't the case (yours only works with mixed
> prefix/postfix), then I can only explain it like this:
>
>    ++E  is the same as: (E:=E+1; E)        # that final E is an lvalue
>
>    E++ is the same as: (T:=E; E:=E+1; T)

Yes.

>
> the final T /is/ an lvalue, but not the right one! You can't use it to
> modify E.

AISI that T would be (or, if you prefer, would be converted to) an rvalue.

>
> That wouldn't work for me anyway because T is a transient value
> (typically stored on the stack, register or unaccessible temporary -
> it's got to exist somewhere!) with no lvalue. It's similar to this:
>
>    A+B is the same as: (T:=A+B; T)
>
> It's clear that ++(A+B) can't work unless you change what ++ means (eg.
> ++A now means (A+1) because whatever ++ modifies is not accessible).

It's similar if A were a struct. You could have

A.F

but you could not have

(A + 4).F

The LHS of the . operation, in this case, has to be an lvalue.

>
> If that's how your approach works, then it would be unorthogonal:
>
>      ++(E++)  works
>      (++E)++  doesn't

I have it the other way round.

++E would consume and produce an lvalue.
E++ would consume an lvalue and produce an rvalue.

This appears to be the same as in C/C++ as mentioned at

https://en.cppreference.com/w/cpp/language/operator_incdec

>
> even though you'd expect E to be 102 in both cases (and to deliver 101
> in both cases too).

I wouldn't expect ++(E++) to work at all. E++ produces an rvalue which
would be no good as input to ++E as ++E requires an lvalue.

Prefix and postfix ++ are different operators, despite the visual
similarity.

> And:
>
>      ++ ++ E  works
>      E ++ ++  doesn't

That I agree with, which makes your earlier comments more puzzling. I am
not sure what you were driving at.

--
James Harris

On 08/11/2022 16:29, David Brown wrote:
> On 08/11/2022 14:24, James Harris wrote:

....

> You can't stop everything - those evil programmers have better
> imaginations than any well-meaning language designer.  But you can try.
>  Aim to make it harder to write convoluted code, and easier to write
> clearer code.  And try to make the clearer code more efficient, to
> reduce the temptation to write evil code.

I agree

....

>> In a similar way, programming can be hard when other programmers write
>> constructs we don't like. I agree that it's best for a language to
>> help programmers write readable and comprehensible programs - and even
>> to make them the easiest to write, if possible - but the very
>> flexibility which may allow them to do so may also give then the
>> freedom to write code we don't care for. I don't think one can
>> legislate against that.
>>
>
> I'm not sure it is the same - after all, if some one exercises their
> rights to speak gibberish, or to give long, convoluted and
> incomprehensible speaches, the listener has the right to go away, ignore
> them, or fall asleep.  It's harder for a compiler to do that!

I'm not worried about the compiler. As long as it can make sense of a
piece of code then it can compile it. It's the human I am concerned
about, especially the poor old maintenance programmer!

--
James Harris

On 07/11/2022 20:59, David Brown wrote:
> On 07/11/2022 20:24, James Harris wrote:
>> On 07/11/2022 14:58, David Brown wrote:
>>> On 07/11/2022 12:55, James Harris wrote:

....

>>>> So it should be possible to combine multiple ++
>>>> operators arbitrarily. For example,
>>>>
>>>>    ++E + E++
>>>>    ++E++
>>>>    V = V++
>>>>
>>>> Expressions such as those would have a defined meaning. The actual
>>>> meaning is less important than it being well defined and so
>>>> something a programmer can rely on.
>>>
>>> I disagree entirely
>>
>> Good. :)
>>
>>> - unless you include giving an error message saying the programmer
>>> should be fired for writing gibberish as "well defined and something
>>> you can rely on".  I can appreciate not wanting such things to be
>>> run-time undefined behaviour, but there is no reason at all to insist
>>> that it is acceptable by the compiler.
>>
>> As I said to Dmitry, if one wants to prohibit the above then one has
>> to define what exactly is being prohibited and to be careful not
>> thereby to prohibit something else that may be more legitimate.
>> Further, such a prohibition is an additional rule the programmer has
>> to learn.
>
> No one said this was easy!  Though Dmitry had some suggestions of rules
> to try.
>
> These prohibitions aren't really additional rules for the programmer to
> learn - it is primarily about disallowing things that a good programmer
> is not going to write in the first place.  No one should actually care
> if "++E++" is allowed or not, because they should never write it.

Yet a programmer may find such an expression in someone else's code.

> Prohibiting it means you don't have to specify the order these operators
> are applied, or whether the expression must be evaluated for
> side-effects twice, or any of the rest of it.  The only people that will
> have to learn something extra are the sort of programmers who think it
> is smart to write line noise.

And the programmers who have to read such code.

>
>>
>> All in all, ISTM better to define such expressions. The programmer is
>> not forced to use them but at least if they are present in code and
>> well defined then their meaning will be plain.
>>
>
> No, the meaning will /not/ be plain.  That's the point.  Ideally you
> should only allow constructs that do exactly what they appear to do,
> without the reader having to study the manuals to understand some
> indecipherable gibberish that is technically legal code but completely
> alien to them because no sane programmer would write it.

There are tradeoffs. Make a language too simple and while it will be
easy to learn programs written in it will he indecipherable. By
contrast, make a language too complex and it becomes harder to learn and
programs written in it can still be indecipherable except to veterans.

AISI somewhere between those two extremes is a sweet spot in which a
language is reasonably easy to learn, and programs written in it would
naturally be reasonably easy to understand.

>
>> Take the first one,
>>
>>    ++E + E++
>>
>> It could be defined fairly easily. If operands to + are defined to
>> appear as though they were evaluated left then right and the ++
>> operators are set to be of higher precedence and defined to take
>> effect as soon as they are evaluated than
>>
>>    ++E + E++
>>
>> would evaluate as though the operations were
>>
>>    ++E; E++; +
>>
>
> Then define it as "syntax error" and insist the programmer writes it
> sensibly.

It's not a typical syntax error. Each operator would have the correct
number of operators.

Further, it may not be known whether the expression is well defined or
not until run time. Consider two pointers, p0 and p1.

++(*p0) + (*p1)++

AIUI in some languages if p0 and p1 point to different locations then
the expression is well defined. If they point to the same location,
however, then the effect is not well defined.

There's no need for that complexity and uncertainty. Why not, instead,
say that the expression is defined to function as though the operands
were evaluated in a specific order? Wouldn't that be easier for a
programmer to understand and rely on?

>
> I cannot conceive of a reason to have a pre-increment operator in a
> modern language, nor would I want post-increment to return a value (nor
> any other kind of assignment).  Ban side-effects in expressions -
> require a statement.  "x = y + 1;" is a statement, so it can affect "x".
>  "y++;" is a statement - a convenient abbreviation for "y = y + 1;".
> "++x" no longer exists, and "x + x++;" makes no sense because it mixes
> an expression and a statement.
>
> What is the cost?  The programmer might have to split things into a few
> lines - but we have much bigger screens and vastly bigger disks than the
> days when C was born.  The programmer might need a few extra temporary
> variables - these are free with modern compiler techniques.
>
> Ask yourself why "++x;" and the like exist in languages like C.  The
> reason is that early compilers were weak - they were close to dumb
> translators into assembly, and if you wanted efficient results using the
> features of the target processor, you needed to write your code in a way
> that mimicked the actual processor instructions.  "INC A" was faster
> than "ADD A, 1", so you write "x++" rather than "x = x + 1".  This is no
> longer the case in the modern world.

To be clear, my motivation for including ++x and x++ is not about any of
those things but is all about readability and (to a lesser extent)
writability. Some intentions are more naturally and more simply
expressed with autoincrement or autodecrement. If they can be used to
make code /clearer/ then ISTM it is worth doing the work to try to
include them.

Against that, however, is the concern that their inclusion may encourage
programmers to write code which is unnecessarily cryptic. It /may/ be
better to require programmers to code x = x + 1 or similar instead. ATM
the jury is out.

....

>> I am aware that it might make optimisation harder to achieve but that
>> would only apply in some cases and is still, IMO, better than simply
>> saying "that's not defined".
>>
>> IOW I welcome your disagreement but don't understand it!
>>
>
> I think it is great that you are happy to discuss this and I try my bes
> to explain it.

Thanks, I appreciate the input!

Have to say that each of these discussions that we in this group have
over what would appear to be minutiae well illustrate how much time it
can take to resolve even tiny decisions in the design of a language!

--
James Harris