Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> We don't have good words for 16 bit, 32 bit, and 64 bit values. "Plyte" and "dyner"
> have been proposed, but they haven't caught on, largely because they were
> consciously silly. It might have been a joke or it might have been an attempt to be
> cutesy. If we did have accepted words they would be far preferable to uint32_t and
> the like.

Malcolm, "plyte" and "dyner" have never been proposed by anyone other
than you, because you misspelled them. They're listed in the Jargon
File as "playte" and "dynner". And they were deliberate jokes.

http://www.catb.org/jargon/html/P/playte.html
http://www.catb.org/jargon/html/D/dynner.html

If you want to argue that we should have words for 16-bit and 32-bit
quantities, don't distract from your point with this silliness.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> wrote:
> On 11/05/2021 13:38, Bart wrote:
> >
> > ? u64 add3(u64 a, b, c)
>
> Ugly types, but allowing the type to be given once in the parameters is
> not a bad idea. It would not be good in C (because of C's way of
> expressing pointers - "uint64_t foo(uint64_t a, *b)" would be bad). But
> for a different language in which the pointer bit is attached to the
> type rather than the identifier, it would work.
<snip>

Actually, pointers are smallest problem, after all normal C declaration
can use single type name to define multiple variables. AFAICS
big problem is that for prototypes that would lead to ambigous
syntax:

int foo(long a, b, c);

and

int foo(long a, int, float);

are syntactically indistinguishable, so in the first one 'b' and
'c' nust be types. One can not omit parameters name from definition,
so in principle there is no ambiguity for function definitions.
But having significanly different rules for prototypes and
definitions would be ugly. Also, there is practical advantage
that one can copy line from definition to get valid and correct
prototype.

--
Waldek Hebisch

On Tuesday, 11 May 2021 at 17:51:49 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > We don't have good words for 16 bit, 32 bit, and 64 bit values. "Plyte" and "dyner"
> > have been proposed, but they haven't caught on, largely because they were
> > consciously silly. It might have been a joke or it might have been an attempt to be
> > cutesy. If we did have accepted words they would be far preferable to uint32_t and
> > the like.
> Malcolm, "plyte" and "dyner" have never been proposed by anyone other
> than you, because you misspelled them. They're listed in the Jargon
> File as "playte" and "dynner".
>
I think I did misspell them. I didn't coin them, however. Spelling might not be settled
anyway.

On 2021-05-11, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 11/05/2021 13:38, Bart wrote:
>> >
>> > ? u64 add3(u64 a, b, c)
>>
>> Ugly types, but allowing the type to be given once in the parameters is
>> not a bad idea. It would not be good in C (because of C's way of
>> expressing pointers - "uint64_t foo(uint64_t a, *b)" would be bad). But
>> for a different language in which the pointer bit is attached to the
>> type rather than the identifier, it would work.
><snip>
>
> Actually, pointers are smallest problem, after all normal C declaration
> can use single type name to define multiple variables. AFAICS
> big problem is that for prototypes that would lead to ambigous
> syntax:
>
> int foo(long a, b, c);
>
> and
>
> int foo(long a, int, float);
>
> are syntactically indistinguishable, so in the first one 'b' and
> 'c' nust be types. One can not omit parameters name from definition,
> so in principle there is no ambiguity for function definitions.
> But having significanly different rules for prototypes and
> definitions would be ugly. Also, there is practical advantage
> that one can copy line from definition to get valid and correct
> prototype.

Your analysis is not very well stated here.

C is already ambiguous in this regard. A parser for the C language must
sometimes know whether or not an identifier has been declared as a type
name.

The problem we have with

int foo(long a, b, c);

is this. Parameter declarations are declarations like all others. They
introduce new identifiers in their own scope. So, even if "a" is already
an existing type name (or anything else), it is redeclared as a
parameter of type long.

The above is existing syntax. If b, and c are typedef names, then

int foo(long a, b, c);

is a valid declaration going back all the way to ANSI C 89.

So if we give any other meaning to this declaration, no matter how aptly
we do that, we are in fact changing the meaning of an existing
construct, which is bad.

Secondly, if we want the meaning to be that b and c are declared along
with a to be of type long, that means we are redeclaring b and c.

Thus, it has to work even if b and c are already typedef names at file
scope! There cannot be any hacks in place which try to keep the old
meaning working under some conditions, like b and c being existing
typedefs.

Here is one way it can work: have semicolon termination on parameter
declarations:

int foo(long a, b, c;);

awkward syntax with an akward parse.

Here is another idea. In declarations (everwhere) support a comma
operator for the sake of declaring multiple identifiers. Here is how
that works:

int (a, b, c = 42); // three variables of type int

Currently, a declarator can have parentheses in and around it:

int (a), (b), c;

This is necessary for overriding precedence:

int *a[3], (*b)[3];

but there is no comma operator available within the parentheses. The
existing comma separates declarators.

The comma within the parentheses would allow a single declarator
syntactic unit to express multiple declarators.

int *a[3], (*(b, c[4]))[3];
^^^^^^^^^

Here b and c[4] are declared to be of type "pointer to array of 3 int".

b just that pointer, and c is an array of 4 such pointers.

So with this, we can write:

int foo(long (a, b, *c));

Problem solved. Or problem introduced, depending on viewpoint.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 11/05/2021 18:31, Kaz Kylheku wrote:
> On 2021-05-11, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:

>> Actually, pointers are smallest problem, after all normal C declaration
>> can use single type name to define multiple variables. AFAICS
>> big problem is that for prototypes that would lead to ambigous
>> syntax:
>>
>> int foo(long a, b, c);
>>
>> and
>>
>> int foo(long a, int, float);
>>
>> are syntactically indistinguishable, so in the first one 'b' and
>> 'c' nust be types. One can not omit parameters name from definition,
>> so in principle there is no ambiguity for function definitions.
>> But having significanly different rules for prototypes and
>> definitions would be ugly. Also, there is practical advantage
>> that one can copy line from definition to get valid and correct
>> prototype.
>
> Your analysis is not very well stated here.
>
> C is already ambiguous in this regard. A parser for the C language must
> sometimes know whether or not an identifier has been declared as a type
> name.
>
> The problem we have with
>
> int foo(long a, b, c);
>
> is this. Parameter declarations are declarations like all others. They
> introduce new identifiers in their own scope. So, even if "a" is already
> an existing type name (or anything else), it is redeclared as a
> parameter of type long.
>
> The above is existing syntax. If b, and c are typedef names, then
>
> int foo(long a, b, c);
>
> is a valid declaration going back all the way to ANSI C 89.

What is 'long a' supposed to mean; does it declare one parameter or two?

I've solved this problem myself, an in a language where you don't know
what anything is until a subsequent, so the syntax as to be unambiguous.
That requires certain rules:

* Parameters are either all named (types+names), or none are named (just
types). (In my language, names are needed for all defined functions. The
choice exists only for FFI imports, where names allow for keyword and
optional parameters.)

* If the next parameter starts with two consecutive identifiers, the
first is assumed to be the name of a user type, the second its name. (In
other cases there are other cues.)

So in an example like yours:

foo(long a, b, c)

'long' is a standard type, and is followed by a name, so this is a list
of 3 parameters a, b, c of type 'long'.

foo(a, b, c, d)

These need to be 4 unnamed parameters of user types a, b, c, d.

foo(a b, c d)

There are two named parameters, b of type a, and d of type c. It sounds
awkward trying to explain it, but in practice it works very well. Even
better when it always knows whether any name is a type as is the case
with C, then it's easy!

This is not so different from the set of declarations you see in a
struct definition, except that uses ";" to start a new type and name(s),
this uses "," which might introduce a new type or a new name. If that
bothers people, ";" can be used here too.

> Here is another idea. In declarations (everwhere) support a comma
> operator for the sake of declaring multiple identifiers. Here is how
> that works:
>
> int (a, b, c = 42); // three variables of type int
>
> Currently, a declarator can have parentheses in and around it:
>
> int (a), (b), c;
>
> This is necessary for overriding precedence:
>
> int *a[3], (*b)[3];
>
> but there is no comma operator available within the parentheses. The
> existing comma separates declarators.
>
> The comma within the parentheses would allow a single declarator
> syntactic unit to express multiple declarators.
>
> int *a[3], (*(b, c[4]))[3];
> ^^^^^^^^^
>
> Here b and c[4] are declared to be of type "pointer to array of 3 int".
>
> b just that pointer, and c is an array of 4 such pointers.
>
> So with this, we can write:
>
> int foo(long (a, b, *c));
>
> Problem solved. Or problem introduced, depending on viewpoint.

I think this makes C declarations, already complex, even more so!

Declaring several names with the same base type (the one on the extreme
left) is already solved. The problem is with modifiers (*, [] and () for
pointers, arrays and functions) which are appplied to each name, not to
the base type.

The would need a more radical change to the syntax (allow modifiers to
prefix the base types), which would be anathema to C programmers; it
would be far too sensible! They would have to stick with wrapping a
particular combination inside a typedef first.

On 11/05/2021 16:17, David Brown wrote:
> On 11/05/2021 16:14, Bart wrote:

> There used to be a strange poster here who prefaced their files with:
>
> #define R return
> #define G goto
> ...
>
> There is no doubt that "R 1;" is shorter than "return 1;". Do you think
> that too means it is a good idea?

Not for this example, since writing 'return' is not onerous. But if the
language required ((__Return__)) for example, then I might think again.

(My language now makes writing 'goto' optional, and also 'return' when
the expression is in the 'return path' anyway (last expression executed
before it would run into end-of-function). That makes it more FP-like,
but I tend to write 'return' anyway for clarity.)

If

> I've noticed you are not particularly concerned about the language used
> for forums.
>

The subject was integer overflow, which is a universal topic, that can
apply to any language which will all run on the same hardware as C. C's
handling of it is controversial, but when talking about it, you are only
concerned with integer types that are signed or unsigned.

No need to have to over-pedantically specify the exact syntax that C
uses for such types; a typical target machine will use i32 or i64, or
maybe u32 and u64, and that's it basically.

But if I was posting examples of actual C code, then that's when I have
to write them properly.

On 11/05/2021 18:12, Malcolm McLean wrote:
> On Tuesday, 11 May 2021 at 17:51:49 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>>> We don't have good words for 16 bit, 32 bit, and 64 bit values. "Plyte" and "dyner"
>>> have been proposed, but they haven't caught on, largely because they were
>>> consciously silly. It might have been a joke or it might have been an attempt to be
>>> cutesy. If we did have accepted words they would be far preferable to uint32_t and
>>> the like.
>> Malcolm, "plyte" and "dyner" have never been proposed by anyone other
>> than you, because you misspelled them. They're listed in the Jargon
>> File as "playte" and "dynner".
>>
> I think I did misspell them. I didn't coin them, however. Spelling might not be settled
> anyway.
>

The gimmick seems to be to introduce 'y', so:

byte = bite
playte = plate
dynner = dinner

But the terms aren't really appropriate: if a bite is 8 bits, you don't
get a plateful with 16 bits, or a whole dinner with 32. Not even a snack.

I seem to remember 'gulp' being used for 8 bytes, which seems a better
fit. Apart from the spelling; so maybe 'guylp'.

On 11/05/2021 19:09, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 11/05/2021 13:38, Bart wrote:
>>>
>>> ? u64 add3(u64 a, b, c)
>>
>> Ugly types, but allowing the type to be given once in the parameters is
>> not a bad idea. It would not be good in C (because of C's way of
>> expressing pointers - "uint64_t foo(uint64_t a, *b)" would be bad). But
>> for a different language in which the pointer bit is attached to the
>> type rather than the identifier, it would work.
> <snip>
>
> Actually, pointers are smallest problem, after all normal C declaration
> can use single type name to define multiple variables. AFAICS
> big problem is that for prototypes that would lead to ambigous
> syntax:
>
> int foo(long a, b, c);
>
> and
>
> int foo(long a, int, float);
>
> are syntactically indistinguishable, so in the first one 'b' and
> 'c' nust be types. One can not omit parameters name from definition,
> so in principle there is no ambiguity for function definitions.

That is a good point, and one I hadn't thought about. Making changes to
language syntax is always a risky business!

As an aside, it looks like omitting parameter names /might/ be coming to
a C standard sometime soon (it is already possible in C++).

<https://habr.com/en/company/badoo/blog/512802/>

> But having significanly different rules for prototypes and
> definitions would be ugly. Also, there is practical advantage
> that one can copy line from definition to get valid and correct
> prototype.
>

On 11/05/2021 18:09, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 11/05/2021 13:38, Bart wrote:
>>>
>>> ? u64 add3(u64 a, b, c)
>>
>> Ugly types, but allowing the type to be given once in the parameters is
>> not a bad idea. It would not be good in C (because of C's way of
>> expressing pointers - "uint64_t foo(uint64_t a, *b)" would be bad). But
>> for a different language in which the pointer bit is attached to the
>> type rather than the identifier, it would work.
> <snip>
>
> Actually, pointers are smallest problem, after all normal C declaration
> can use single type name to define multiple variables. AFAICS
> big problem is that for prototypes that would lead to ambigous
> syntax:
>
> int foo(long a, b, c);
>
> and
>
> int foo(long a, int, float);
>
> are syntactically indistinguishable, so in the first one 'b' and
> 'c' nust be types.

> One can not omit parameters name from definition,
> so in principle there is no ambiguity for function definitions.
> But having significanly different rules for prototypes and
> definitions would be ugly. Also, there is practical advantage
> that one can copy line from definition to get valid and correct
> prototype.

The rules stay exactly the same: definitions need named parameters; with
prototypes they are optional.

The only thing that needs to change (something I wasn't even aware of
until I tried it just now), is that with prototypes, you can optionally
name or not name individual parameters.

That needs to be restricted (it's very sloppy anyway). So this example
of yours wouldn't be allowed:

int foo(long a, int, float);

The first parameter is named, so the rest should be too.

On Wednesday, 12 May 2021 at 13:27:48 UTC+1, Bart wrote:
> On 11/05/2021 18:09, anti...@math.uni.wroc.pl wrote:
> > David Brown <david...@hesbynett.no> wrote:
> >> On 11/05/2021 13:38, Bart wrote:
> >>>
> >>> ? u64 add3(u64 a, b, c)
> >>
> >> Ugly types, but allowing the type to be given once in the parameters is
> >> not a bad idea. It would not be good in C (because of C's way of
> >> expressing pointers - "uint64_t foo(uint64_t a, *b)" would be bad). But
> >> for a different language in which the pointer bit is attached to the
> >> type rather than the identifier, it would work.
> > <snip>
> >
> > Actually, pointers are smallest problem, after all normal C declaration
> > can use single type name to define multiple variables. AFAICS
> > big problem is that for prototypes that would lead to ambigous
> > syntax:
> >
> > int foo(long a, b, c);
> >
> > and
> >
> > int foo(long a, int, float);
> >
> > are syntactically indistinguishable, so in the first one 'b' and
> > 'c' nust be types.
>
>
> > One can not omit parameters name from definition,
> > so in principle there is no ambiguity for function definitions.
> > But having significanly different rules for prototypes and
> > definitions would be ugly. Also, there is practical advantage
> > that one can copy line from definition to get valid and correct
> > prototype.
> The rules stay exactly the same: definitions need named parameters; with
> prototypes they are optional.
>
> The only thing that needs to change (something I wasn't even aware of
> until I tried it just now), is that with prototypes, you can optionally
> name or not name individual parameters.
>
> That needs to be restricted (it's very sloppy anyway). So this example
> of yours wouldn't be allowed:
> int foo(long a, int, float);
> The first parameter is named, so the rest should be too.
>
Parameter names can clash with macros. e.g.

double clamp(double x, double min, double max);

So the parameters are left nameless as an undesireable but hard to avoid
fix.

On 2021-05-12, Bart <bc@freeuk.com> wrote:
> The only thing that needs to change (something I wasn't even aware of
> until I tried it just now), is that with prototypes, you can optionally
> name or not name individual parameters.

Not knowing basics like this is consistent with you only being here to
discuss your own projects, and not out of an interest in the C language.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 12/05/2021 15:30, Kaz Kylheku wrote:
> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>> The only thing that needs to change (something I wasn't even aware of
>> until I tried it just now), is that with prototypes, you can optionally
>> name or not name individual parameters.
>
> Not knowing basics like this is consistent with you only being here to
> discuss your own projects, and not out of an interest in the C language.
>

It's consistent with every programmer not knowing about rarely used
corner cases in any language.

But when it matters, eg. in my private C compiler, then that particular
aspect is handled as expected, since I used it to check before
cross-checking with gcc:

void fn(int a, int,int, int b);

generates this ST entry:

:fn----------------------procid...
Param: a---------pm_normal
Param: Anon------pm_normal
Param: Anon------pm_normal
Param: b---------pm_normal

Since the discussion veered on to writing more compact parameter
declarations, then I'm giving the benefit of my experience in having,
you know, actually done it, when everyone else is saying how hard it
would be.

On 12/05/2021 15:29, Malcolm McLean wrote:
> On Wednesday, 12 May 2021 at 13:27:48 UTC+1, Bart wrote:

>> That needs to be restricted (it's very sloppy anyway). So this example
>> of yours wouldn't be allowed:
>> int foo(long a, int, float);
>> The first parameter is named, so the rest should be too.
>>
> Parameter names can clash with macros. e.g.
>
> double clamp(double x, double min, double max);
>
> So the parameters are left nameless as an undesireable but hard to avoid
> fix.
>

I don't get it. By the time a piece code is parsed, all macros will have
been expanded.

If you're saying that you can't always use a desired parameter name
because it happens to be a macro name, then that's always going to a
problem anyway. For example, it would stop you using such names in a
function definition as well.

With C, since the actual names in a prototype parameter list don't
really matter, you can alter them, or even use dummy ones:

double clamp(double _1, _2, _3);

This (using the suggested new feature) now tells you even more clearly
that there are 3 parameters, all of the same double type.

On 12/05/2021 15:30, Kaz Kylheku wrote:
> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>> The only thing that needs to change (something I wasn't even aware of
>> until I tried it just now), is that with prototypes, you can optionally
>> name or not name individual parameters.
>
> Not knowing basics like this is consistent with you only being here to
> discuss your own projects, and not out of an interest in the C language.

I've looked at it some more, and realised that this is restriction (not
allowing mixed types/types+names) is not necessary in C because it will
always know if an identifier represents a type while it is parsing.

So I decided to implement my idea in my C compiler. This code:

typedef float a;
typedef char* d;

void fn(a b,c, d e, d,d);

now correctly produces this parameter list where some are named and some
not:

Param: b---------pm_normal Mode:float
Param: c---------pm_normal Mode:float
Param: e---------pm_normal Mode:ref schar
Param: Anon------pm_normal Mode:ref schar
Param: Anon------pm_normal Mode:ref schar

If I then go on to write a function definition, which needs

void fn(a b,c, d e, d x,d y){}

it is updated to:

Param: b---------pm_normal Mode:float
Param: c---------pm_normal Mode:float
Param: e---------pm_normal Mode:ref schar
Param: x---------pm_normal Mode:ref schar
Param: y---------pm_normal Mode:ref schar

With this example upthread:

int foo(long a, int, float);

it shows:

Param: a---------pm_normal Mode:int
Param: Anon------pm_normal Mode:int
Param: Anon------pm_normal Mode:float

With more typical usage:

uint64_t add3(uint64_t a, b, c) {return a+b+c;}

Param: a---------pm_normal Mode:ullong
Param: b---------pm_normal Mode:ullong
Param: c---------pm_normal Mode:ullong

In about 30 minutes' effort, and with a dozen lines of code, I've fixed
a bugbear of a million C programmers that's been present for nearly 50
years. And without needing to bring any other languages into it.

So fuck you.

On 2021-05-12, Bart <bc@freeuk.com> wrote:
> On 12/05/2021 15:30, Kaz Kylheku wrote:
>> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>>> The only thing that needs to change (something I wasn't even aware of
>>> until I tried it just now), is that with prototypes, you can optionally
>>> name or not name individual parameters.
>>
>> Not knowing basics like this is consistent with you only being here to
>> discuss your own projects, and not out of an interest in the C language.
>>
>
> It's consistent with every programmer not knowing about rarely used
> corner cases in any language.

Function declarations without identifiers in C are used daily.

It appears as if you haven't spent so much as a week seriously
programming in C.

Yet, here you are; and not as a newbie to ask questions about C,
apparently.

On 12/05/2021 17:50, Kaz Kylheku wrote:
> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>> On 12/05/2021 15:30, Kaz Kylheku wrote:
>>> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>>>> The only thing that needs to change (something I wasn't even aware of
>>>> until I tried it just now), is that with prototypes, you can optionally
>>>> name or not name individual parameters.
>>>
>>> Not knowing basics like this is consistent with you only being here to
>>> discuss your own projects, and not out of an interest in the C language.
>>>
>>
>> It's consistent with every programmer not knowing about rarely used
>> corner cases in any language.
>
> Function declarations without identifiers in C are used daily.
>
> It appears as if you haven't spent so much as a week seriously
> programming in C.

I've been exposed to C for over 25 years, mostly with having to deal
with C APIs, so you'd think I'd be familiar with function prototypes.

I'm not anyway talking about parameter lists without names, but
parameters lists where SOME parameters are named, and some aren't. Which
are rarer (why would you do that anyway?).

> Yet, here you are; and not as a newbie to ask questions about C,
> apparently.

No. I fix languages. C is too far gone in most cases, but I was able to
show that a fix could be viable for this particular aspect of syntax.

You're welcome.

Bart <bc@freeuk.com> writes:
>On 12/05/2021 15:30, Kaz Kylheku wrote:

>In about 30 minutes' effort, and with a dozen lines of code, I've fixed
>a bugbear of a million C programmers that's been present for nearly 50
>years.

Hyperbole much? In 42 years of hard-core C programming, working with
thousands of other C programmers, not one has ever requested such a
foolish feature in the C compiler.

Leaving aside the maintenance and readability issues,
most programmers even avoid constructs like:

uint32_t variant, opcode;

in favor of

uint32_t variant; /**< Variant, domain is 0..<HIGHEST_VARIANT> */
uint32_t opcode; /**< Instruction opcode. domain is 0..255 */

for a dozen different reasons, including such things as making
'cvs diff'/'svn diff'/'git diff' output more readable, patches
easier to apply and to reason about, or for adding doxygen comments used
to produce API documentation (and back in the day, to avoid needing
to repunch a card when changing a declaration - much easier to just
add a new card to the deck).

On 2021-05-12, Bart <bc@freeuk.com> wrote:
> On 12/05/2021 17:50, Kaz Kylheku wrote:
>> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>>> On 12/05/2021 15:30, Kaz Kylheku wrote:
>>>> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>>>>> The only thing that needs to change (something I wasn't even aware of
>>>>> until I tried it just now), is that with prototypes, you can optionally
>>>>> name or not name individual parameters.
>>>>
>>>> Not knowing basics like this is consistent with you only being here to
>>>> discuss your own projects, and not out of an interest in the C language.
>>>>
>>>
>>> It's consistent with every programmer not knowing about rarely used
>>> corner cases in any language.
>>
>> Function declarations without identifiers in C are used daily.
>>
>> It appears as if you haven't spent so much as a week seriously
>> programming in C.
>
> I've been exposed to C for over 25 years, mostly with having to deal
> with C APIs, so you'd think I'd be familiar with function prototypes.

Hey, you said it.

Myself, I've been exposed to decades of weather reports and news for 50
years; yet I'm neither economist nor meteorologist.

> I'm not anyway talking about parameter lists without names, but
> parameters lists where SOME parameters are named, and some aren't. Which
> are rarer (why would you do that anyway?).

That happens all the time, and I can easily find code examples.

Often they are situations like this:

void set_parameters(simulation_t *, double gravity, double temperature);

The double parameters have the same type and could be mixed up, so they
get names. The simulation parameter is self-evident, and so doesn't
require a name; a name like "simulation_t *sim" doesn't inform.

The language would be more complicated if it required all parameters
to give names or none at all, and that rule would be irksome in
situations like the above.

Why it would be more complicated is that the simplest way to implement
it would be to keep the underlying grammar as it is now, and then add
an additional semantic constraint rule.

A language which doesn't have such a rule is slightly simpler than
one which has it.

>> Yet, here you are; and not as a newbie to ask questions about C,
>> apparently.
>
> No. I fix languages. C is too far gone in most cases, but I was able to

What other languages are you fixing, and do you post to their newsgroups?

> show that a fix could be viable for this particular aspect of syntax.

That is nonproductive, since none of your fixes are being taken
seriously anywhere and being integrated.

If you were serious, you would implement them in some open source
C compiler.

You'd show that the patched compiler can still build a major OS distro,
while demonstrating all the new features with test cases.

Everyone here can think of better alternatives to almost every design
choice in C; you're not informing anyone of anything surprising or new.

I suspect nearly everyone here uses numerous other languages.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 12/05/2021 18:47, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 12/05/2021 15:30, Kaz Kylheku wrote:
>
>> In about 30 minutes' effort, and with a dozen lines of code, I've fixed
>> a bugbear of a million C programmers that's been present for nearly 50
>> years.
>
> Hyperbole much?

People (apart from the diehards in this group) generally like that
feature and miss it in C.

In 42 years of hard-core C programming, working with
> thousands of other C programmers, not one has ever requested such a
> foolish feature in the C compiler.

Well, this feature was in other languages I'd been exposed to when I
first just starting off. Including Ada:

function Divide (Left, Right : Float) return Float

> Leaving aside the maintenance and readability issues,
> most programmers even avoid constructs like:
>
> uint32_t variant, opcode;
>
> in favor of
>
> uint32_t variant; /**< Variant, domain is 0..<HIGHEST_VARIANT> */
> uint32_t opcode; /**< Instruction opcode. domain is 0..255 */

This is an anti-pattern. For example taking two or more related
parameters that share the same type, written in a way that makes it
impossible to ever not share that type, and make them independent.

Which means writing duplicate copies of their types; making maintenance
(eg. change of type) more effort and now error prone; and removing a
useful cue for the reader that those have a linked type.

> for a dozen different reasons, including such things as making
> 'cvs diff'/'svn diff'/'git diff' output more readable, patches
> easier to apply and to reason about, or for adding doxygen comments used
> to produce API documentation (and back in the day, to avoid needing
> to repunch a card when changing a declaration - much easier to just
> add a new card to the deck).

Being able to write (float x,y) doesn't stop anyone from still writing
(float x, float y), or splitting it across multiple lines, or adding
comments.

We're also not punching cards anymore, and these days C has some of the
most onerous-to-type type names, so do C programmers REALLY prefer to
have to write:

uint32_t makergb(uint_8 r, uint8_t b, int8_t c) // ** see note

instead of:

uint32_t makergb(uint_8 r, g, b)

Or are they making up reasons why it would be a terrible idea because
they know C is in reality never going to adapt this syntax?

(** The int8_t typo was deliberate, but writing b and c instead of g and
b wasn't! I guess I was too preoccupied with getting the _t's just right.)

On 12/05/2021 19:58, Kaz Kylheku wrote:
> On 2021-05-12, Bart <bc@freeuk.com> wrote:

> What other languages are you fixing, and do you post to their newsgroups?

Yes, I've made suggestions about a few others. And I've replaced some
troublesome tools (assemblers, linkers or build tools) with my own. But
otherwise I don't need to get involved with others as much as with C.

C comes up in APIs as I said; I've used C as an intermediate code for
some compilers which means generating huge amounts of C code and doing
battle with compilers; I've written a C compiler of sorts which has been
used to compile perhaps a million lines of open source code; and I've
written a number of programs in actual C, but probably only 30-40Kloc.

Also, C is the closest to my own systems language, where I have firm
ideas about how such a language should work.

>> show that a fix could be viable for this particular aspect of syntax.
>
> That is nonproductive, since none of your fixes are being taken
> seriously anywhere and being integrated.

Unlike your own fix:

> int foo(long (a, b, *c));

> Problem solved. Or problem introduced, depending on viewpoint.

?

> If you were serious, you would implement them in some open source
> C compiler.

Why? My experiment showed that a C compiler can be easily tweaked to
have that feature that I suggested. So if it's not already there, then C
programmers simply don't want it. There are innumerable other
improvements that could be done first.

One purpose of my C compiler was to try out new ideas, some of them
originating in mine.

> You'd show that the patched compiler can still build a major OS distro,
> while demonstrating all the new features with test cases.

I've got rid of most of my C code-bases. My C compiler is a private
project that is mainly good for newly written code. I still have
sqlite3.c lying around, but first, here's that new feature at work:

C:\archive\cx\big>type test.c # demo program
#include <stdio.h>

int add3(int a,b,c) {return a+b+c;} // new feature

int main(void) {
printf("%d\n", add3(10,20,30));
}

C:\archive\cx\big>bcc test -run
Compiling test.c to test.exe
60

Now see if that big program still works:

C:\archive\cx\big>bcc sqlite3 shell -run
Compiling sqlite3.c to sqlite3.asm
Compiling shell.c to shell.asm
Assembling to sqlite3.exe

SQLite version 3.25.3/BCC 2018-11-05 20:37:38
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>

(This compiles about 250,000 lines of C, using the modified compiler.)

> Everyone here can think of better alternatives to almost every design
> choice in C; you're not informing anyone of anything surprising or new.

But I actually do something about it. Here I showed a feature is
possible which a few said was not viable.

Not bad for someone who's barely progressed beyond 'hello world'
according to you.

On 2021-05-12, Bart <bc@freeuk.com> wrote:
> On 12/05/2021 19:58, Kaz Kylheku wrote:
>> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>
>
>> What other languages are you fixing, and do you post to their newsgroups?
>
> Yes, I've made suggestions about a few others. And I've replaced some
> troublesome tools (assemblers, linkers or build tools) with my own. But
> otherwise I don't need to get involved with others as much as with C.
>
> C comes up in APIs as I said; I've used C as an intermediate code for

Anything you call has an ABI. You can interface with components without
processing any C code. Just declare what they are doing in your own
language and have a way to have compatible calling conventions.

> Unlike your own fix:
>
> > int foo(long (a, b, *c));
>
> > Problem solved. Or problem introduced, depending on viewpoint.

I don't actually want that, in any shape or form, though.

>> If you were serious, you would implement them in some open source
>> C compiler.
>
> Why? My experiment showed that a C compiler can be easily tweaked to
> have that feature that I suggested.

Everyone knows that such a tweak is already possible.

You have to demonstrate it in a compiler that people actually use.

The tweak was easy in part because:

- No test cases, or documentation.
- No switch to turn off the extension so the compiler accepts ISO C.
- No optional diagnostic to diagnose the use of the extension
while accepting it.
- No end users to whom to roll out the feature for alpha and
beta testing.

>> Everyone here can think of better alternatives to almost every design
>> choice in C; you're not informing anyone of anything surprising or new.
>
> But I actually do something about it.

No, actually you don't. At the end of the day, all you do is
talk about it. That's the net effect.

> Here I showed a feature is possible which a few said was not viable.

You've not actually shown that anything is viable in a real
world sense.

Tweaking a parser in 15 minutes isn't what makes it viable or not.

Getting the feature into C, the language, is a big social problem, not a
problem of you hacking a few lines in your private compiler.

The most widely used C dialect for new work nowadays is C99.
Nothing new is getting into that, by definition, because you can't go
back to 1999 and rewrite history.

If you add anything to C now, it will be in C202x.

Poeple will only be able to use that if they have a C202x
conforming compiler, and are willing to throw away C99 or C90
compatibility.

Probably another 20 years or more will have to pass before
coders can just casually use that feature in code that is to be
portable "anywhere".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 12/05/2021 20:35, Bart wrote:
> On 12/05/2021 18:47, Scott Lurndal wrote:

>> In 42 years of hard-core C programming, working with
>> thousands of other C programmers, not one has ever requested such a
>> foolish feature in the C compiler.

> so do C programmers REALLY prefer to
> have to write:
>
>  uint32_t makergb(uint_8 r, uint8_t b, int8_t c)    // ** see note
>
> instead of:
>
>  uint32_t makergb(uint_8 r, g, b)
>
> Or are they making up reasons why it would be a terrible idea because
> they know C is in reality never going to adapt this syntax?

This is part of an actual header
(https://github.com/sal55/langs/blob/master/bignum.h) from one of my
rare C programs:

----------------------------
extern int bn_add (Bignum c, Bignum a, Bignum b); // c = a+b
extern int bn_sub (Bignum c, Bignum a, Bignum b); // c = a-b

extern int bn_mul (Bignum c, Bignum a, Bignum b); // c = a*b
extern int bn_mulp (Bignum c, Bignum a, Bignum b, // c = a*b
int prec);

extern int bn_div (Bignum c, Bignum a, Bignum b, // c = a/b
int prec);

extern int bn_idiv (Bignum c, Bignum a, Bignum b); // c = a/b
extern int bn_irem (Bignum c, Bignum a, Bignum b); // c = a%b
extern int bn_idivrem (Bignum c, Bignum r,
Bignum a, Bignum b); // c = a/b,
r=a%b

----------------------------

Notice it makes extensive use of repeated parameter types. Also that
some had to overflow onto a second line, as repeating made everything
longer.

This is what it looks like using my new feature:

----------------------------
extern int bn_add (Bignum c, a, b); // c = a+b
extern int bn_sub (Bignum c, a, b); // c = a-b

extern int bn_mul (Bignum c, a, b); // c = a*b
extern int bn_mulp (Bignum c, a, b, int prec); // c = a*b

extern int bn_div (Bignum c, a, b, int prec); // c = a/b

extern int bn_idiv (Bignum c, a, b); // c = a/b
extern int bn_irem (Bignum c, a, b); // c = a%b
extern int bn_idivrem (Bignum c, r, a, b); // c = a/b, r=a%b
----------------------------

Notice that those longer sets of parameters now fit comfortably on one
line. Note also that the parameter names now dominate each parameter
list rather than loads of Bignums.

Anyone who claims this is not better than the original (or that this is
a 'foolish' feature!) is either crazy, or lying.

The header in this format still worked, but only using my revised
compiler with its 12 lines of extra code.

>> In 42 years of hard-core C programming, working with
>> thousands of other C programmers, not one has ever requested such a
>> foolish feature in the C compiler.

Then 1000s have wasted an awful lot of effort on pointless repetitions
and unnecessarily cluttered code.

Or, as seems to be often the case with getting around C shortcomings,
myriad different solutions with macros have been devised.

On Wednesday, 12 May 2021 at 23:03:20 UTC+1, Bart wrote:
>
> extern int bn_idiv (Bignum c, a, b); // c = a/b
>
> Then 1000s have wasted an awful lot of effort on pointless repetitions
> and unnecessarily cluttered code.
>
> Or, as seems to be often the case with getting around C shortcomings,
> myriad different solutions with macros have been devised.
>
This is a common programming fallacy.
Teach programming 101 and ask the students to come up with a list of
good operations for subroutines, and they'll come up with suggestions
like sqrt() and log(). Math-like subroutines.
So programming languages end up being designed so that people who
implement math-like subroutines have the optimal working environment.

But in fact user-declared math-like subroutines are pretty rare. Yes, they exist,
but the vast majority of code does something else. Something much messier
and with fewer conventions, and with a a mix of types.

Take this one, for example, from real code

void InvalidateAndCheckForExpiredAnnotationTip( const RealPoint *previousCursorPoint, const RealPoint *cursorPoint );

is it really helpful to have special syntax, just because the two parameters happen to be of the same type?

Bart <bc@freeuk.com> writes:
>On 12/05/2021 18:47, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 12/05/2021 15:30, Kaz Kylheku wrote:
>>
>>> In about 30 minutes' effort, and with a dozen lines of code, I've fixed
>>> a bugbear of a million C programmers that's been present for nearly 50
>>> years.
>>
>> Hyperbole much?
>
>People (apart from the diehards in this group) generally like that
>feature and miss it in C.

You speak for nobody but yourself. Find even one more person who
likes that feature, or is even aware that such a feature might be
available.

>
>
> In 42 years of hard-core C programming, working with
>> thousands of other C programmers, not one has ever requested such a
>> foolish feature in the C compiler.
>
>Well, this feature was in other languages I'd been exposed to when I
>first just starting off. Including Ada:
>
> function Divide (Left, Right : Float) return Float

We're talking about C programmers, which number in
the hundreds of thousands. Not the 200 people that
have actually written production code in ADA.

It's clear from the rest that you don't have any real-world
programming experience on real projects that live for years
and need to be maintained by teams of programmers, many who
were not part of the project from the start.

>> uint32_t variant; /**< Variant, domain is 0..<HIGHEST_VARIANT> */
>> uint32_t opcode; /**< Instruction opcode. domain is 0..255 */

This is an anti-pattern. For example taking two or more related
parameters that share the same type, written in a way that makes it
impossible to ever not share that type, and make them independent.

If you need things that share the same type, abstract it with typedef.

Editors have had 'find' functionality for forty years too.

On 12/05/2021 22:44, Kaz Kylheku wrote:
> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>> On 12/05/2021 19:58, Kaz Kylheku wrote:
>>> On 2021-05-12, Bart <bc@freeuk.com> wrote:
>>
>>
>>> What other languages are you fixing, and do you post to their newsgroups?
>>
>> Yes, I've made suggestions about a few others. And I've replaced some
>> troublesome tools (assemblers, linkers or build tools) with my own. But
>> otherwise I don't need to get involved with others as much as with C.
>>
>> C comes up in APIs as I said; I've used C as an intermediate code for
>
> Anything you call has an ABI. You can interface with components without
> processing any C code. Just declare what they are doing in your own
> language and have a way to have compatible calling conventions.

Creating the FFI is the easy bit. Binding a specific library is another
matter entirely. I created a tool to do it out of my C compiler; with a
small library like OpenGL, I ended up with something like this:

https://github.com/sal55/langs/blob/master/Examples/opengl.m

This required manual tweaking to deal with macros or other matters
specific to C. But on a big library like GTK (700 headers and 350Kloc)
the process yields a 25Kloc file including 3000 macros that have to be
dealt with manually.

>> Why? My experiment showed that a C compiler can be easily tweaked to
>> have that feature that I suggested.
>
> Everyone knows that such a tweak is already possible.

Your post yesterday suggested otherwise.

>
> You have to demonstrate it in a compiler that people actually use.
>
> The tweak was easy in part because:

> - No test cases, or documentation.
> - No switch to turn off the extension so the compiler accepts ISO C.
> - No optional diagnostic to diagnose the use of the extension
> while accepting it.
> - No end users to whom to roll out the feature for alpha and
> beta testing.
>

> No, actually you don't. At the end of the day, all you do is
> talk about it. That's the net effect.

And yet, I was able to change that Bignum header file to benefit from
that feature.

(If anyway wants to use some of these additions to the language, without
waiting for acceptance into the standard, then 20 years for widespread
availabilty, there are ways to short-cut the process.

That is to use a preprocessor (not the crappy macro preprocessor of C),
or a transpiler. This converts new-style C into standard C and fed into
a regular compiler.)

>> Here I showed a feature is possible which a few said was not viable.
>
> You've not actually shown that anything is viable in a real
> world sense.
>
> Tweaking a parser in 15 minutes isn't what makes it viable or not.

> Getting the feature into C, the language, is a big social problem, not a
> problem of you hacking a few lines in your private compiler.
>
> The most widely used C dialect for new work nowadays is C99.
> Nothing new is getting into that, by definition, because you can't go
> back to 1999 and rewrite history.
>
> If you add anything to C now, it will be in C202x.
>
> Poeple will only be able to use that if they have a C202x
> conforming compiler, and are willing to throw away C99 or C90
> compatibility.
>
> Probably another 20 years or more will have to pass before
> coders can just casually use that feature in code that is to be
> portable "anywhere".
>

You are just nitpicking:

* People have said that nobody wants the feature; that's the first thing
I had to fight. (See my example posted 30 minutes ago of a real program.)

* People have said they my proposal won't work. But it does. The reasons
they put forward were purely syntactic and semantic; nothing was said
about all the 'social' problems that you have only now brought up
(presumably to keep me firmly in my place)

* People (you) have made their own proposal which is too complicated.

I'm not saying this should all be done in 5 minutes. The process could
have been started decades ago, but apparently nobody wants it.

But why am I surprised? This group has always been like that. I remember
long discussions about how pointless binary literals were (since real
programmers can just use hex, or better still, some complicated macro,
but that only works up to 8 bits) . Yet, they are now widespread in
implementations.