On 27/08/2023 01:44, Ben Bacarisse wrote:
>
> As it happens, I am not with David on this. There are many matters on
> which I think an appeal to authority carries significant weight. I
> don't know DMR's opinion of underscores (the code in K&R is indicative
> but not exactly conclusive), but I would take more time considering it
> than I would Kevin's or Barbara's. It's just one way to simplify life.

Ah, now it is /your/ turn to misunderstand the "appeal to authority"
fallacy - or at least, to Malcolm's use of it or my objection to his use.

It's fine to "appeal to authority" as supporting evidence for a claim,
and it is absolutely appropriate to view DMR's opinion on C style in
higher standing than Kevin's or Barbara's.

But it is fallacious to think of DMR's opinion as being proof that
Malcolm's theories are correct - at best, they could be supporting
evidence. (Even experts are wrong sometimes.) It is fallacious to
appeal to DMR's authority when his coding and writing don't actually
support Malcolm's ideas at all. It is fallacious to cherry-pick bits of
code that appear to support it, rather than looking at a wider selection
of his code. It is fallacious to consider his code written in different
circumstances than code written now (his tools had very limited lengths
of significant characters in identifiers).

There's nothing wrong with using expert or authority opinion to bolster
an argument, when it is not fallacious.

On 27/08/2023 17:50, David Brown wrote:

[about named parameters]

>
> You can have both "void foo(int a, int b);" and "void foo(int b, int
> a);" declarations visible at the same time.

The function is 'void foo(int, int)' ... the a and b tags are supposed
to be self-documenting.

>
> And if one translation unit defined "void foo(int a, int b);", while
> another declared "void foo(int b, int a);" and used that with named
> parameters, you would not get the correct call.

You'd need something like: void foo(int a:x, int b:y);

where the parameter names are x and y (and a and b don't really matter).

All that buys you is the ability to call foo with the paramaters
out-of-order:
foo(y:100, x:5); // foo(5, 100);

And I don't think it really gains you anything.

But ... default values, maybe that would be more useful?

void foo(int a:x, int b:y:5);
void bar(int a:x, int b:y:5, int c:z:2);

So you could say:
foo(100); // foo(100, 5);
foo(y:1); // error - no default for x
bar(100, z:4); // bar(100, 5, 4);
bar(z:4, y:1, x:20); // bar(20, 1, 4);

On Sunday, 27 August 2023 at 18:21:00 UTC+1, David Brown wrote:
> On 27/08/2023 01:44, Ben Bacarisse wrote:
> >
> > As it happens, I am not with David on this. There are many matters on
> > which I think an appeal to authority carries significant weight. I
> > don't know DMR's opinion of underscores (the code in K&R is indicative
> > but not exactly conclusive), but I would take more time considering it
> > than I would Kevin's or Barbara's. It's just one way to simplify life.
> Ah, now it is /your/ turn to misunderstand the "appeal to authority"
> fallacy - or at least, to Malcolm's use of it or my objection to his use.
>
> It's fine to "appeal to authority" as supporting evidence for a claim,
> and it is absolutely appropriate to view DMR's opinion on C style in
> higher standing than Kevin's or Barbara's.
>
> But it is fallacious to think of DMR's opinion as being proof that
> Malcolm's theories are correct - at best, they could be supporting
> evidence. (Even experts are wrong sometimes.) It is fallacious to
> appeal to DMR's authority when his coding and writing don't actually
> support Malcolm's ideas at all. It is fallacious to cherry-pick bits of
> code that appear to support it, rather than looking at a wider selection
> of his code. It is fallacious to consider his code written in different
> circumstances than code written now (his tools had very limited lengths
> of significant characters in identifiers).
>
> There's nothing wrong with using expert or authority opinion to bolster
> an argument, when it is not fallacious.
>
No. Denis Ritchie didn't like const. But to say "const is a bad idea because
Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie
almost certainly knows what he is talking about, and obvioulsy the committee
has shown their inferiority inm many other ways. But you have to look at the
arguments Ritchie used, not just say "Ritchie says so, so it is".

However identifers are a. bit different. Ritchie was no expert on Colas. But,
as I said, if he said "Coke is nicer than Pepsi" then that makes it true that
Coke is nicer than Pepsi, for him. And it is a counter-example to the claim
that everyone prefers Pepsi.

Ritchie used identifiers without spaces to separate the words. So that disproves
the claim that everyone agree that this style is wrong. And of course because
he is a familiar and well respected figure, he's a good counterexampe to choose.
But I also gave Caesar as a counter-example, and of course no-one would say
that Caesar was an authority on C. But Ceasar is someone everyone would have
heard of. God also gave His Torah to the Jewish people, without spaces.

So on my side, Caesar, Denis Ritchie, and God. That's clearly no "no-one". Whilst
had I offered Kevin and Barbara from the office I could be accused of trawling
through a vast bank of people to cherry pick

But the actual argument from Denis Ritchie was a bit different.. Calls to the
standard library are very common in C code. And Ritchie chose the names of
the standard library functions. So, since he agreed with my style, where a standard
library function consists of two English words, they are not separated by an underscore.
Now consistency is important, and Denis Ritchie, as the author of C, set the C "house style".

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> No. Denis Ritchie didn't like const. But to say "const is a bad idea because
> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie
> almost certainly knows what he is talking about, and obvioulsy the committee
> has shown their inferiority inm many other ways. But you have to look at the
> arguments Ritchie used, not just say "Ritchie says so, so it is".

I am sorry, I am a bit lazy today and cannot be bothered to do web
searches. What exactly are Ritchie's arguments against "const"?

I cannot think of any, but I have heard some that lend support
to having, and properly using, "const".

br,
KK

On 27/08/2023 20:18, Richard Harnden wrote:
> On 27/08/2023 17:50, David Brown wrote:
>
> [about named parameters]
>
>>
>> You can have both "void foo(int a, int b);" and "void foo(int b, int
>> a);" declarations visible at the same time.
>
> The function is 'void foo(int, int)' ... the a and b tags are supposed
> to be self-documenting.
>
>>
>> And if one translation unit defined "void foo(int a, int b);", while
>> another declared "void foo(int b, int a);" and used that with named
>> parameters, you would not get the correct call.
>
> You'd need something like: void foo(int a:x, int b:y);
>
> where the parameter names are x and y (and a and b don't really matter).

Why would you want two names here? You want the parameters to have a
single name each (which should be, as you say, self-documenting).

>
> All that buys you is the ability to call foo with the paramaters
> out-of-order:
>     foo(y:100, x:5); // foo(5, 100);
>
> And I don't think it really gains you anything.

The real gain comes from not using them out-of-order by mistake. If
"foo" is defined as "void foo(int x, int y)" and you write :

foo(y : 100, x : 5)

then it could either be counted as "foo(5, 100)", or it could be flagged
as an error. I wouldn't mind it being an error, and having to write
"foo(x : 5, y : 100)" - that would help keep the source code consistent.
The key point is that you don't write "foo(100, 5)" thinking
mistakenly that foo was defined as "foo(int y, int x)".

So for me at least, the biggest benefit of named parameters is to catch
potential errors. User convenience at the call site is secondary.

>
> But ... default values, maybe that would be more useful?
>
> void foo(int a:x, int b:y:5);
> void bar(int a:x, int b:y:5, int c:z:2);
>
> So you could say:
>     foo(100); // foo(100, 5);
>     foo(y:1); // error - no default for x
>     bar(100, z:4); // bar(100, 5, 4);
>     bar(z:4, y:1, x:20); // bar(20, 1, 4);
>
>

I'm not so convinced about default values. They can be handy (in
languages that support them) when adding new parameters to existing
functions, but are not necessarily a great idea. There is a school of
thought in C++ that instead of declaring "void foo(int x, int y = 1)"
you should declare two functions - "void foo(int x)" and "void foo(int
x, int y)" - where "void foo(int x)" calls "foo(x, 1)". Some people
feel it gives you more control - you can differentiate between leaving
out the argument and coincidentally picking the default value.

On 27/08/2023 19:18, Richard Harnden wrote:
> On 27/08/2023 17:50, David Brown wrote:
>
> [about named parameters]
>
>>
>> You can have both "void foo(int a, int b);" and "void foo(int b, int
>> a);" declarations visible at the same time.
>
> The function is 'void foo(int, int)' ... the a and b tags are supposed
> to be self-documenting.
>
>>
>> And if one translation unit defined "void foo(int a, int b);", while
>> another declared "void foo(int b, int a);" and used that with named
>> parameters, you would not get the correct call.
>
> You'd need something like: void foo(int a:x, int b:y);
>
> where the parameter names are x and y (and a and b don't really matter).

I don't understand: what are 'a' and 'b' for then? If both lots of names
are used, then let them be alternatives:

int count_e(int FS, char* filename:string) {...}

When FS is 'F' the second parameter represents a filename; when 'S', it
is a string containing the data. Those two uses can be given more apt names:

count_e('F', filename:"input.txt");
count_e('S', string:"This is some literal text");

> All that buys you is the ability to call foo with the paramaters
> out-of-order:
>     foo(y:100, x:5); // foo(5, 100);
>
> And I don't think it really gains you anything.

It helps to document the meaning of each argument in calls like 'f(1, 0,
1, 1)'.

It avoids having to remember the order of the arguments (but you need to
remember the parameter names).

It allows the parameter ordering to be changed without affecting
call-sites (but only if positional arguments are used).

> But ... default values, maybe that would be more useful?

With those it will be considerably more useful. They are useful also on
their own. For example, start with this:

int F(int a, int b);

Write 1000s of lines of code with instances of F(x,y). Then you decide
that sometimes, an extra parameter is needed (or this could even be
temporary to help debugging). Make that extra parameter optional:

int F(int a, int b, int newflag=0);

'=0' is my syntax for a default value. Like this, existing code will
compile unchanged, and will pass newflag as 0. Only new code that needs
to use that flag need to supply that new argument.

> void foo(int a:x, int b:y:5);
> void bar(int a:x, int b:y:5, int c:z:2);

A rather strange syntax though.

> So you could say:
>     foo(100); // foo(100, 5);
>     foo(y:1); // error - no default for x
>     bar(100, z:4); // bar(100, 5, 4);
>     bar(z:4, y:1, x:20); // bar(20, 1, 4);

On 27/08/2023 07:54, Malcolm McLean wrote:
> On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote:
....
>> The sources I found indicate that it wasn't intended to be read by anyone
>> other than the person who wrote it.
>>
> Just goes to show that you can believe everything you read.
> Do you think that is remotely plausible?

The Wikipedia article on Scriptio Continua gives precisely that
explanation. That explanation is bracketed by two citations - it's not
clear which of the two is most relevant:

Moore, F. C. T. (2001). "Scribes and Texts: A Test Case for Models of
Cultural Transmission". The Monist. 84 (3): 421.
doi:10.5840/monist200184325. JSTOR 27903738. Retrieved March 24, 2023.

Parkes, M. B. "Antiquity: Aids for Inexperienced Readers and the
Prehistory of Punctuation". Pause and Effect: An Introduction to the
History of Punctuation in the West. Berkeley: U of California, 1993. 10–11.

I would not recommend dismissing that thesis out of hand without first
following up on those citations and learning what reasons they give for
believing it to be true.

David Brown <david.brown@hesbynett.no> writes:
> On 25/08/2023 20:59, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> Any resolution here would place restrictions on which functions could
>>> support named parameters - such as consistent declarations and
>>> definitions, but it would be impossible (in general) to check them.
>>
>> Any parameter names in a call would just have to be consistent with
>> the names in the visible prototype. I don't see a problem.
>
> You can have both "void foo(int a, int b);" and "void foo(int b, int
> a);" declarations visible at the same time.

So have a rule that the most recent declaration applies. If you write
two declarations with deliberately misleading parameter names, you get
what you deserve.

> And if one translation unit defined "void foo(int a, int b);", while
> another declared "void foo(int b, int a);" and used that with named
> parameters, you would not get the correct call.

True. So don't do that.

> If you required the compiler to enforce that all declarations and
> definitions of a function used the same parameter names, then you'd do
> much better. (There is still scope for errors, but would be basically
> the same as we have today for calling functions with incorrect numbers
> or types of arguments.) But that would conflict with existing code
> that was valid before.

I might have advocated requiring parameter names to be consistent
(basically making parameter names as well as their types, part of the
function signature), but it's too late for that.

> So you'd need a new syntax to say that a function must have all its
> declarations having consistent parameter names. You'd have to write
> "void foo(int a static, int b static);" !

No, I don't think you do.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Richard Harnden <richard.nospam@gmail.com> writes:
> On 27/08/2023 17:50, David Brown wrote:
> [about named parameters]
>
>> You can have both "void foo(int a, int b);" and "void foo(int b, int
>> a);" declarations visible at the same time.
>
> The function is 'void foo(int, int)' ... the a and b tags are supposed
> to be self-documenting.
>
>> And if one translation unit defined "void foo(int a, int b);", while
>> another declared "void foo(int b, int a);" and used that with named
>> parameters, you would not get the correct call.
>
> You'd need something like: void foo(int a:x, int b:y);
>
> where the parameter names are x and y (and a and b don't really matter).

Why? What's the point of having two names for the same parameter?

> All that buys you is the ability to call foo with the paramaters
> out-of-order:
> foo(y:100, x:5); // foo(5, 100);
>
> And I don't think it really gains you anything.

The main point is letting calls be more self-documenting. (Names like
a, b, x, and y don't illustrate that very well.)

I think this was triggered by bool parameters, where you could have a
call like:
func(blah, true, true, false);
A reader can't tell what "true, true, false" means without being *very*
familiar with func()'s signature. With named arguments, you could write
that as:
func(blah, text_mode: true, highlight: true, color: false);

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-27, Bart <bc@freeuk.com> wrote:
> On 27/08/2023 05:24, Kaz Kylheku wrote:
>> On 2023-08-26, Bart <bc@freeuk.com> wrote:
>>> With the feature in place, people can create their own wrapper functions
>>> and make their own choices.
>>
>> Yikes; just what we need: people scrambling the order of arguments
>> to standard functions, using their own local names.
>>
>> Quick, which one is the destination?
>>
>> strcpy(goat: userid, fish: uid);
>>
>
> That's an excellent idea, I've just changed my FFI strcpy, which hadn't
> had parameter names up to now, to this:
>
> func strcpy(ichar goat, fish="<Insert string here>")ichar
>
> Now I can write:
>
> strcpy(fish:"Hello", goat:str)
>
> or even just:
>
> strcpy(str)
>
> Silly, but at least I can do it. The more useful, non-silly applications
> outnumber the silly ones.
>
> Remember that C's macro processor can do a LOT worse:
>
> #define int float
>
> #define while if

This argument is like: crack can do worse, so just give the kids
cigarettes.

If required, positional parameters are going to be callable using named
arguments, the named arguments must be a mandatory part of the function
definition.

A redeclaration with different names must be diagnosable error.

In the case of C structures, names count for compatibility.

Two structure types that are structurally identical, occurring in
different translation units must have the same member names, in the
same order, in order to be considered compatible.

The only way this can be sanely introduced into C with backward
compatibility is if there is a separate way to introduce the
parameter names used for named calling, like this:

char *strcpy(const char * : dest, char * : src);

THe syntax for the declaread identifier in a function declaration
would be:

ident_opt
| ident ':' ident_opt
| ':' ident
| /* nothing */

The identifier after the ':' is available for specifying named
arguments. Only functions which are declared this way support
named arguments.

If at least one parameter of a function declaration uses the
above ':' syntax, then all parameters implicitly have argument
names, even without ussing ':'.

When only the ':' is given, not followed by an identifier,
then that specifies a named argument which inherits the parameter
name: foo : is the same as foo : foo.

If a parameter is asssociated with an argument name implicitly,
without the use of the : syntax above, because some other
parameter uses the : syntax, then the argument name is
the same as the parameter name, as if : were given followed
by nothing or by a repetition of the parameter name.

Constraints:

- The argument names need not be the same as the parameter names,
but must be unique among themselves.

- An argument name associated with a parameter may be the same
as that parameter name; but must not be the same as any other
parameter name.

- If a declaration of a function uses argument names, all other
declarations of the function must use argument names, and the
names must be the same. The parameter names need not be.

Implementations could support a macro to enable names, like

#define __stdc_argument_names 1

Inside a header, it could be like:

#if __stdc_argument_names
#define __aname(x) : x
#else
#define __aname(x)
#endif

Then strcpy would look like:

char *strcpy(char *__dst __aname(dst),
const char *__src __aname(src));

If the application enables __stdc_argument_names, then it
can no longer do this:

#define __stdc_argument_names 1
#include <string.h>

// Error: non-arg-name declaration follows arg-name
char *strcpy(char *destination, const char *source);

It must ensure that there are argument names which match
the standard-given ones:

// Explicitly given: param names can be arbitrary
char *strcpy(char *foo : dst, const char *bar : src);

// Explicitly given: param names omitted

char *strcpy(char * : st, const char * : src);

// Implicitly derived from param names
char *strcpy(char *dst :, const char *src);

// Error, wrong names
char *strcpy(char *src :, const char *dst);

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 8/27/23 6:45 PM, Kaz Kylheku wrote:
> On 2023-08-27, Bart <bc@freeuk.com> wrote:
>> On 27/08/2023 05:24, Kaz Kylheku wrote:
>>> On 2023-08-26, Bart <bc@freeuk.com> wrote:
>>>> With the feature in place, people can create their own wrapper functions
>>>> and make their own choices.
>>>
>>> Yikes; just what we need: people scrambling the order of arguments
>>> to standard functions, using their own local names.
>>>
>>> Quick, which one is the destination?
>>>
>>> strcpy(goat: userid, fish: uid);
>>>
>>
>> That's an excellent idea, I've just changed my FFI strcpy, which hadn't
>> had parameter names up to now, to this:
>>
>> func strcpy(ichar goat, fish="<Insert string here>")ichar
>>
>> Now I can write:
>>
>> strcpy(fish:"Hello", goat:str)
>>
>> or even just:
>>
>> strcpy(str)
>>
>> Silly, but at least I can do it. The more useful, non-silly applications
>> outnumber the silly ones.
>>
>> Remember that C's macro processor can do a LOT worse:
>>
>> #define int float
>>
>> #define while if
>
> This argument is like: crack can do worse, so just give the kids
> cigarettes.
>
> If required, positional parameters are going to be callable using named
> arguments, the named arguments must be a mandatory part of the function
> definition.
>
> A redeclaration with different names must be diagnosable error.

No, that would be a very backwards breaking change.

changing names might make the function not callable with named
parameters, but only "old style" with just values listed.

>
> In the case of C structures, names count for compatibility.
>
> Two structure types that are structurally identical, occurring in
> different translation units must have the same member names, in the
> same order, in order to be considered compatible.

Why? what difference can that make to the actual code generted?

In C, the structures don't even need the same type name to be compatible.

Again, that becomes a breaking change, and one that actually takes a lot
of work to actually detect the error to give a diagnostic.

>
> The only way this can be sanely introduced into C with backward
> compatibility is if there is a separate way to introduce the
> parameter names used for named calling, like this:
>
>
> char *strcpy(const char * : dest, char * : src);

That is one option to make named parameter calls optional.

If you do that, THEN you can make not match an error.

>
> THe syntax for the declaread identifier in a function declaration
> would be:
>
> ident_opt
> | ident ':' ident_opt
> | ':' ident
> | /* nothing */
>
> The identifier after the ':' is available for specifying named
> arguments. Only functions which are declared this way support
> named arguments.
>
> If at least one parameter of a function declaration uses the
> above ':' syntax, then all parameters implicitly have argument
> names, even without ussing ':'.
>
> When only the ':' is given, not followed by an identifier,
> then that specifies a named argument which inherits the parameter
> name: foo : is the same as foo : foo.
>
> If a parameter is asssociated with an argument name implicitly,
> without the use of the : syntax above, because some other
> parameter uses the : syntax, then the argument name is
> the same as the parameter name, as if : were given followed
> by nothing or by a repetition of the parameter name.
>
> Constraints:
>
> - The argument names need not be the same as the parameter names,
> but must be unique among themselves.
>
> - An argument name associated with a parameter may be the same
> as that parameter name; but must not be the same as any other
> parameter name.
>
> - If a declaration of a function uses argument names, all other
> declarations of the function must use argument names, and the
> names must be the same. The parameter names need not be.
>
> Implementations could support a macro to enable names, like
>
> #define __stdc_argument_names 1
>
> Inside a header, it could be like:
>
> #if __stdc_argument_names
> #define __aname(x) : x
> #else
> #define __aname(x)
> #endif
>
> Then strcpy would look like:
>
> char *strcpy(char *__dst __aname(dst),
> const char *__src __aname(src));
>
> If the application enables __stdc_argument_names, then it
> can no longer do this:
>
> #define __stdc_argument_names 1
> #include <string.h>
>
> // Error: non-arg-name declaration follows arg-name
> char *strcpy(char *destination, const char *source);
>
> It must ensure that there are argument names which match
> the standard-given ones:
>
> // Explicitly given: param names can be arbitrary
> char *strcpy(char *foo : dst, const char *bar : src);
>
> // Explicitly given: param names omitted
>
> char *strcpy(char * : st, const char * : src);
>
> // Implicitly derived from param names
> char *strcpy(char *dst :, const char *src);
>
> // Error, wrong names
> char *strcpy(char *src :, const char *dst);
>

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> If required, positional parameters are going to be callable using named
> arguments, the named arguments must be a mandatory part of the function
> definition.

Named arguments are already mandatory for function definitions (barring
old-style definitions).

I don't think it's practical to make them mandatory for function
declarations. That would break tons of existing code.

My suggestion: If a function declaration doesn't use parameter names,
you can't call it with named arguments. (You can always write your own
declaration for an existing function.)

> A redeclaration with different names must be diagnosable error.

That would break existing code. My suggestion: the names in the *last*
visible declaration before a call can be used in a call. (Strongly
suggested best practice would be to use consistent names.)

[...]

> The only way this can be sanely introduced into C with backward
> compatibility is if there is a separate way to introduce the
> parameter names used for named calling, like this:
>
> char *strcpy(const char * : dest, char * : src);

Why not just declare
char *strcpy(const char *dest, char *src);
and use those names in calls, with a few simple rules for when there's
more than one visible declaration?

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:

> On 27/08/2023 01:44, Ben Bacarisse wrote:
>> As it happens, I am not with David on this. There are many matters on
>> which I think an appeal to authority carries significant weight. I
>> don't know DMR's opinion of underscores (the code in K&R is indicative
>> but not exactly conclusive), but I would take more time considering it
>> than I would Kevin's or Barbara's. It's just one way to simplify life.
>
> Ah, now it is /your/ turn to misunderstand the "appeal to authority"
> fallacy - or at least, to Malcolm's use of it or my objection to his
> use.

I did not refer to any supposed fallacy.

> It's fine to "appeal to authority" as supporting evidence for a claim, and
> it is absolutely appropriate to view DMR's opinion on C style in higher
> standing than Kevin's or Barbara's.

That is all I was referring to and all I was commenting on in MM's post.

> But it is fallacious to think of DMR's opinion as being proof that
> Malcolm's theories are correct - at best, they could be supporting
> evidence.

Maybe you went further and were suggesting that he was constructing a
logical argument based on the appeal to authority. If so, I missed
that. I didn't think he was doing that.

--
Ben.

On 2023-08-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
> [...]
>> The only way this can be sanely introduced into C with backward
>> compatibility is if there is a separate way to introduce the
>> parameter names used for named calling, like this:
>
>> char *strcpy(const char * : dest, char * : src);
>
> Why not just declare
> char *strcpy(const char *dest, char *src);
> and use those names in calls, with a few simple rules for when there's
> more than one visible declaration?

In order to prevent

#include <string.h>

// someone adds this somewhere, and arguments get flipped
// downscope of it.
char *strcpy(char *src, const char *dest);

If we are going to have argument names that have a semantic
purpose, I'd like those to be part of the declaration.

If the standard declaration has been included via the proper header, the
program should be defended against an incorrect declaration coming from
somewhere else.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 27/08/2023 23:45, Kaz Kylheku wrote:
> On 2023-08-27, Bart <bc@freeuk.com> wrote:
>> On 27/08/2023 05:24, Kaz Kylheku wrote:
>>> On 2023-08-26, Bart <bc@freeuk.com> wrote:
>>>> With the feature in place, people can create their own wrapper functions
>>>> and make their own choices.
>>>
>>> Yikes; just what we need: people scrambling the order of arguments
>>> to standard functions, using their own local names.
>>>
>>> Quick, which one is the destination?
>>>
>>> strcpy(goat: userid, fish: uid);
>>>
>>
>> That's an excellent idea, I've just changed my FFI strcpy, which hadn't
>> had parameter names up to now, to this:
>>
>> func strcpy(ichar goat, fish="<Insert string here>")ichar
>>
>> Now I can write:
>>
>> strcpy(fish:"Hello", goat:str)
>>
>> or even just:
>>
>> strcpy(str)
>>
>> Silly, but at least I can do it. The more useful, non-silly applications
>> outnumber the silly ones.
>>
>> Remember that C's macro processor can do a LOT worse:
>>
>> #define int float
>>
>> #define while if
>
> This argument is like: crack can do worse, so just give the kids
> cigarettes.

The argument is more like: kids can already legally buy crack, but let's
stop them buying cigarettes. (Which I believe would actually be a safer
habit.)

> The only way this can be sanely introduced into C with backward
> compatibility is if there is a separate way to introduce the
> parameter names used for named calling, like this:
>
>
> char *strcpy(const char * : dest, char * : src);
>
> THe syntax for the declaread identifier in a function declaration
> would be:
>
> ident_opt
> | ident ':' ident_opt
> | ':' ident
> | /* nothing */
>
> The identifier after the ':' is available for specifying named
> arguments. Only functions which are declared this way support
> named arguments.

So what goes inside a function definition? Do you have to write this:

char *strcpy(const char * dest : dest, char * src : src);

Or will all existing definitions need to end up as:

char *strcpy(const char * : dest, char * : src);

with the extra colon? If so, will these identifiers also serve as naming
the parameters for use inside the function?

Could somebody do this:

char *strcpy(const char * dest : src, char * src : dest);

> If at least one parameter of a function declaration uses the
> above ':' syntax, then all parameters implicitly have argument
> names, even without ussing ':'.

> When only the ':' is given, not followed by an identifier,
> then that specifies a named argument which inherits the parameter
> name: foo : is the same as foo : foo.

Sorry, too complicated.

> If a parameter is asssociated with an argument name implicitly,
> without the use of the : syntax above, because some other
> parameter uses the : syntax, then the argument name is
> the same as the parameter name, as if : were given followed
> by nothing or by a repetition of the parameter name.
>
> Constraints:
>
> - The argument names need not be the same as the parameter names,
> but must be unique among themselves.
>
> - An argument name associated with a parameter may be the same
> as that parameter name; but must not be the same as any other
> parameter name.
>
> - If a declaration of a function uses argument names, all other
> declarations of the function must use argument names, and the
> names must be the same. The parameter names need not be.
>
> Implementations could support a macro to enable names, like
>
> #define __stdc_argument_names 1
>
> Inside a header, it could be like:
>
> #if __stdc_argument_names
> #define __aname(x) : x
> #else
> #define __aname(x)
> #endif
>
> Then strcpy would look like:
>
> char *strcpy(char *__dst __aname(dst),
> const char *__src __aname(src));
>
> If the application enables __stdc_argument_names, then it
> can no longer do this:
>
> #define __stdc_argument_names 1
> #include <string.h>
>
> // Error: non-arg-name declaration follows arg-name
> char *strcpy(char *destination, const char *source);
>
> It must ensure that there are argument names which match
> the standard-given ones:
>
> // Explicitly given: param names can be arbitrary
> char *strcpy(char *foo : dst, const char *bar : src);
>
> // Explicitly given: param names omitted
>
> char *strcpy(char * : st, const char * : src);
>
> // Implicitly derived from param names
> char *strcpy(char *dst :, const char *src);
>
> // Error, wrong names
> char *strcpy(char *src :, const char *dst);
>

Yep. That's good way to ensure nobody will use the feature. It needs to
simple to understand and use.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> [...]
>>> The only way this can be sanely introduced into C with backward
>>> compatibility is if there is a separate way to introduce the
>>> parameter names used for named calling, like this:
>>
>>> char *strcpy(const char * : dest, char * : src);
>>
>> Why not just declare
>> char *strcpy(const char *dest, char *src);
>> and use those names in calls, with a few simple rules for when there's
>> more than one visible declaration?
>
> In order to prevent
>
> #include <string.h>
>
> // someone adds this somewhere, and arguments get flipped
> // downscope of it.
> char *strcpy(char *src, const char *dest);

So don't do that.

And don't this either:

#define strcpy(s1, s2) ((strcpy)((s2), (s1)))

> If we are going to have argument names that have a semantic
> purpose, I'd like those to be part of the declaration.
>
> If the standard declaration has been included via the proper header, the
> program should be defended against an incorrect declaration coming from
> somewhere else.

Adding named arguments should be fairly simple (though library functions
additionally defined as macros present some complications). Parameter
names can already be given in a function declaration. I just want to be
able to use them.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-08-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Why not just declare
>>> char *strcpy(const char *dest, char *src);
>>> and use those names in calls, with a few simple rules for when there's
>>> more than one visible declaration?
>>
>> In order to prevent
>>
>> #include <string.h>
>>
>> // someone adds this somewhere, and arguments get flipped
>> // downscope of it.
>> char *strcpy(char *src, const char *dest);
>
> So don't do that.

We could dispense with all sorts of static checking if we "don't do that".

If you don't pass incorrect types to strcpy, you can just declare it as:

char *strcpy();

The named arguments idea is purely a static gadget in which it's
possible to do sanity checks for consistency, which is a good argument
that it should be done.

There are many situations we can't easily check for at translation time.

> Adding named arguments should be fairly simple (though library functions
> additionally defined as macros present some complications). Parameter
> names can already be given in a function declaration. I just want to be
> able to use them.

You have to think of the C implementations that won't fix their
library declarations to the specified names where you'd like your
code to be able to run (if you have the compiler for it).

If this were rolled out, you would face situations where the names
coming from the header are not the right ones, or are completely
absent.

Programs would have to supply their own redeclarations of library
functions to make up for this.

In such a program, it would be a good idea to have those declarations
active even in an implementation that provides the standard-defined
names, so that those redeclarations get checked.

For that reason, it would be useful for a declaration to be able to
somehow assert "I provide argument names for use in calls (check
me against other such declarations)", versus "I'm a regular old
declaration that doesn't assert argument names (I don't speak to the
validity of declarations which do that).".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 8/27/23 19:06, Richard Damon wrote:
> On 8/27/23 6:45 PM, Kaz Kylheku wrote:
>> On 2023-08-27, Bart <bc@freeuk.com> wrote:
>>> On 27/08/2023 05:24, Kaz Kylheku wrote:
>>>> On 2023-08-26, Bart <bc@freeuk.com> wrote:
....
>> In the case of C structures, names count for compatibility.
>>
>> Two structure types that are structurally identical, occurring in
>> different translation units must have the same member names, in the
>> same order, in order to be considered compatible.
>
> Why? what difference can that make to the actual code generted?

Unfortunately, the C99 Rationale doesn't go into any detail about the
reasons for that requirement. I think that requirement is motivated by
the belief that such code is inherently confusing, and should therefore
not be required to work as you might expect it to.

> In C, the structures don't even need the same type name to be compatible.

That was changed in C99. If either structure type is given a tag, the
other one must be given the same tag.

> Again, that becomes a breaking change, and one that actually takes a lot
> of work to actually detect the error to give a diagnostic.

He's not describing a proposed change - that's what the current
requirements are:

"Two types have compatible type if their types are the same. ...
Moreover, two structure, union, or enumerated types declared in separate
translation units are compatible if their tags and members satisfy the
following requirements: If one is declared with a tag, the other shall
be declared with the same tag."

Note the same tag requirement.

"If both are completed anywhere within their respective translation
units, then the following additional requirements apply: there shall be
a one-to-one correspondence between their members such that each pair of
corresponding members are declared with compatible types; if one member
of the pair is declared with an alignment specifier, the other is
declared with an equivalent alignment specifier; and if one member of
the pair is declared with a name, the other is declared with the same name."

Note the same name requirement.

"For two structures, corresponding members shall be declared in the same
order. For two structures or unions, corresponding bit-fields shall have
the same widths. ..." (6.2.7p1)

Note also that this applies only for struct declarations in separate
translation units. Otherwise, struct types are covered only by the "same
type" part of the rule. Struct types declared with member lists are
considered to be new types in that translation unit. (6.7.2.1p10). Doing
so twice with the same tag in the same scope is a constraint violation
(6.7.2.3p1,5). Struct types declared in different scopes or with
different tags or no tag are considered distinct types (6.7.2.3p6). As a
result, two struct types defined in the same translation unit are never
compatible, regardless of how they are defined.

On 27/08/2023 20:18, Malcolm McLean wrote:
> On Sunday, 27 August 2023 at 18:21:00 UTC+1, David Brown wrote:
>> On 27/08/2023 01:44, Ben Bacarisse wrote:
>>>
>>> As it happens, I am not with David on this. There are many matters on
>>> which I think an appeal to authority carries significant weight. I
>>> don't know DMR's opinion of underscores (the code in K&R is indicative
>>> but not exactly conclusive), but I would take more time considering it
>>> than I would Kevin's or Barbara's. It's just one way to simplify life.
>> Ah, now it is /your/ turn to misunderstand the "appeal to authority"
>> fallacy - or at least, to Malcolm's use of it or my objection to his use.
>>
>> It's fine to "appeal to authority" as supporting evidence for a claim,
>> and it is absolutely appropriate to view DMR's opinion on C style in
>> higher standing than Kevin's or Barbara's.
>>
>> But it is fallacious to think of DMR's opinion as being proof that
>> Malcolm's theories are correct - at best, they could be supporting
>> evidence. (Even experts are wrong sometimes.) It is fallacious to
>> appeal to DMR's authority when his coding and writing don't actually
>> support Malcolm's ideas at all. It is fallacious to cherry-pick bits of
>> code that appear to support it, rather than looking at a wider selection
>> of his code. It is fallacious to consider his code written in different
>> circumstances than code written now (his tools had very limited lengths
>> of significant characters in identifiers).
>>
>> There's nothing wrong with using expert or authority opinion to bolster
>> an argument, when it is not fallacious.
>>
> No. Denis Ritchie didn't like const.

That may or may not be true - early C did not have const, but that is no
evidence for saying he didn't like it.

> But to say "const is a bad idea because
> Denis Ritchie didn't support it" is fallacious,

Correct.

> though obvioulsy Denis Ritchie
> almost certainly knows what he is talking about,

That's an assumption, not an "obvious" fact.

> and obvioulsy the committee
> has shown their inferiority inm many other ways.

That's an opinion (and a very unusual one at that), not an "obvious" fact.

> But you have to look at the
> arguments Ritchie used, not just say "Ritchie says so, so it is".

Yes, looking at his reasoning would be helpful, if he explained his
reasoning. I haven't personally read such reasoning, or even heard that
he had written it down. (I read The C Programming Language, many years
ago, but it does not mention "const", as far as I remember.)

But no, you don't have to look at the reasoning behind an expert opinion
to be able to use it appropriately in an argument. Equally, you can use
the reasoning fallaciously. The reason behind an expert's opinions or
comments is just another thing they said.

Since none of your three heroes have made any comments that are relevant
to your argument (and only two of them actually wrote anything at all),
all your use of "appeal to authority" is fallacious. None of them were
programming in modern languages with modern tools, and all had good
reason to write in a compact way. And there are literally billions of
other people who use word separators to make their writing clearer.
(Most of them have not or do not write modern programming code either.)

Can we please stop this now? You are looking more and more absurd with
every word you post. It's embarrassing.

On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > No. Denis Ritchie didn't like const. But to say "const is a bad idea because
> > Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie
> > almost certainly knows what he is talking about, and obvioulsy the committee
> > has shown their inferiority inm many other ways. But you have to look at the
> > arguments Ritchie used, not just say "Ritchie says so, so it is".
> I am sorry, I am a bit lazy today and cannot be bothered to do web
> searches. What exactly are Ritchie's arguments against "const"?
>
> I cannot think of any, but I have heard some that lend support
> to having, and properly using, "const".
>
He write them in a leter tot he committee many years ago.
I believe there was also apost to this newsgroup.

His main focus of ire was "no alias", but he also criticised const.

[Ritchie]

Let me begin by saying that I’m not convinced that even the pre-December qualifiers
(`const’ and `volatile’) carry their weight; I suspect that what they add to the cost of learning
and using the language is not repaid in greater expressiveness.

`Const’ is simultaneously more useful and more obtrusive; you can’t avoid learning about it,
because of its presence in the library interface. Nevertheless, I don’t argue for the extirpation
of qualifiers, if only because it is too late.
....

1. The qualifiers create an inconsistent language

A substantial fraction of the library cannot be expressed in the proposed language.

One of the simplest routines,

char *strchr(const noalias char *s, int c);

can return its first parameter. This first parameter must be declared with `const noalias;’
otherwise, it would be illegal (by the constraints on assignment, 3.3.16.1) to pass the address
of a const or noalias object. That is, the type qualifiers in the prototype are not merely an
optional pleasantry of the interface; they are required, if one is to pass some kinds of data to
this or most other library routines.

Unfortunately, there is no way in X3J11’s language for strchr to return the value it promises to,
because of the semantics of return (3.6.6.4) and casts (3.3.4). Whether the stripping of the const
and noalias qualifiers is done by cast inside strchr, or implicitly by its return statement, strchr
returns a pointer that (because of `const’) cannot be stored through, and (because of `noalias’)
cannot even be dereferenced; by the rules, it is useless. (Incidentally, I think this observation
was made by Tom Plum several years ago; it’s disconcerting that the inconsistency remains.)

Although the plain words of the Standard deny it, plastering the appropriate `non-const’ cast on
an expression to silence a compiler is sometimes safe, because the most probable implementation
of `const’ objects will allow them to be read through any access path, and will diagnose attempts to
change them by generating an access violation fault at run time. That is, in common implementations,
adding or taking away the `const’ qualifier of a pointer can never create any bugs not implicit in the
rule `do not modify a genuine const object through any access path.’

Nevertheless, I must emphasize that this is NOT the rule that X3J11 has written, and that its
library is inconsistent with its language. Someone writing an interpreter
using X3J11/88-001 is perfectly at liberty to (indeed, is advised to) carry with each pointer a
`modifiable’ bit, that (following 3.3.4) remains off when a pointer to a const-
qualified object is cast into a plain pointer. This implementation will prevent many of the real uses
of strchr, for example. I’m thinking of things like

if (p = strchr(q, ‘/’))
*p = ‘ ‘;

which are common and innocuous in C, but undefined by X3J11’s language.

A related observation is that string literals are not of type `array of const char.’ Indeed, the
Rationale (88-004 version) says, `However, string literals do not have [this type], in order to avoid
the problems of pointer type checking, particularly with library functions….’ Should this bald statement
be considered anything other than an admission that X3J11’s rules are screwy? It is ludicrous that
the committee introduces the `const’ qualifier, and also makes strings unwritable, yet is unable to
connect the two conceptions.
.....
compilers will ignore, or
only warn about, casts and assignments that X3J11 says are undefined, people will somehow survive

4. What to do?

Noalias must go. This is non-negotiable.

It must not be reworded, reformulated or reinvented. The draft’s description is badly flawed, but
that is not the problem. The concept is wrong from start to finish. It negates every brave promise
X3J11 ever made about codifying existing practices, preserving the existing body of code, and
keeping (dare I say it?) `the spirit of C.’

Const has two virtues: putting things in read-only memory, and expressing interface restrictions.
For example, saying

char *strchr(const char *s, int c);

is a reasonable way of expressing that the routine cannot change the object referred to by its first argument.
I think that minor changes in wording preserve the virtues, yet eliminate the contradictions in the current scheme.

1) Reword page 47, lines 3-5 of 3.3.4 (Cast operators), to remove the undefinedness of modifying pointed-to
objects, or remove these lines altogether (since casting non-qualified to qualified isn’t discussed explicitly either.)

2) Rewrite the constraint on page 54, lines 14-15, to say that pointers may be assigned without taking
qualifiers into account.

3) Preserve all current constraints against modifying non-modifiable lvalues, that is things of
manifestlyconst-qualified type.

4) String literals have type `const char []’.

5) Add a constraint (or discussion or example) to assignment that makes clear the
illegality of assigning to an object whose actual type is const-qualified, no matter what
access path is used. There is a manifest constraint that is easy to check (left side is not const-
qualified), but also a non-checkable constraint (left side is not secretly const-qualified). The
effect should be that converting between pointers to const- qualified and plain objects is legal
and well-defined; avoiding assignment through pointers that derive ultimately from `const’ objects
is the programmer’s responsibility.

These rules give up a certain amount of checking, but they save the consistency of the language.

[Malcolm]
I think there's an element of politicing in agreeing to const in the last section. His real
object is to get rid of noalias.So he throws the committe a sop. They can have const,
with a few provisos.

On Sunday, 27 August 2023 at 20:56:28 UTC+1, James Kuyper wrote:
> On 27/08/2023 07:54, Malcolm McLean wrote:
> > On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote:
> ...
> >> The sources I found indicate that it wasn't intended to be read by anyone
> >> other than the person who wrote it.
> >>
> > Just goes to show that you can believe everything you read.
> > Do you think that is remotely plausible?
> The Wikipedia article on Scriptio Continua gives precisely that
> explanation. That explanation is bracketed by two citations - it's not
> clear which of the two is most relevant:
>
>
> Moore, F. C. T. (2001). "Scribes and Texts: A Test Case for Models of
> Cultural Transmission". The Monist. 84 (3): 421.
> doi:10.5840/monist200184325. JSTOR 27903738. Retrieved March 24, 2023.
>
> Parkes, M. B. "Antiquity: Aids for Inexperienced Readers and the
> Prehistory of Punctuation". Pause and Effect: An Introduction to the
> History of Punctuation in the West. Berkeley: U of California, 1993. 10–11.
>
> I would not recommend dismissing that thesis out of hand without first
> following up on those citations and learning what reasons they give for
> believing it to be true.
>
Scriptio Continua was used for about 2,000 years. So it's not difficult to read.
This is a knock-down, simple, almost irrefutable point.

However it was eventually abandoned, and text with spaces is easier to read..
That doesn't make text without spaces difficult to read. People work out complex
and rather tendentious theories about why the ancients used Scriptio Continua
and moderns use text separated by spaces.

You need to understand the strength of the simple, obvious argument, before you
try to snipe at it with sophisticated objections.

M.B. Parkes was my teacher at Oxford by the way. He taught me this stuff.

On 28/08/2023 09:42, Malcolm McLean wrote:
> On Sunday, 27 August 2023 at 20:56:28 UTC+1, James Kuyper wrote:
>> On 27/08/2023 07:54, Malcolm McLean wrote:
>>> On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote:
>> ...
>>>> The sources I found indicate that it wasn't intended to be read by anyone
>>>> other than the person who wrote it.
>>>>
>>> Just goes to show that you can believe everything you read.
>>> Do you think that is remotely plausible?
>> The Wikipedia article on Scriptio Continua gives precisely that
>> explanation. That explanation is bracketed by two citations - it's not
>> clear which of the two is most relevant:
>>
>>
>> Moore, F. C. T. (2001). "Scribes and Texts: A Test Case for Models of
>> Cultural Transmission". The Monist. 84 (3): 421.
>> doi:10.5840/monist200184325. JSTOR 27903738. Retrieved March 24, 2023.
>>
>> Parkes, M. B. "Antiquity: Aids for Inexperienced Readers and the
>> Prehistory of Punctuation". Pause and Effect: An Introduction to the
>> History of Punctuation in the West. Berkeley: U of California, 1993. 10–11.
>>
>> I would not recommend dismissing that thesis out of hand without first
>> following up on those citations and learning what reasons they give for
>> believing it to be true.
>>
> Scriptio Continua was used for about 2,000 years.

It was closer to 1000 years. There have been plenty of totally absurd
ideas that have lasted far longer, and had far more consequence - the
"four humors" theory of medicine being a prime example. Age is no
indication of quality.

And Scriptio Continua was by no means universal. The old Latin and
Greek writings we have include some with spaces, and some with
inter-word dots, as well as some without spacing of any kind.

> So it's not difficult to read.

Non-sequitor, and total nonsense. Text (in alphabetic script) without
some kind of word spacing /is/ difficult to read. Once it became more
important for many people to read each written text, legibility became
more important compared to other factors (such as the cost of writing
material), and word spacing very quickly overtook. It did so because it
was easier to read - after all, there are no other benefits to word spacing.

> This is a knock-down, simple, almost irrefutable point.

No. It is bollocks.

>
> However it was eventually abandoned,

"Eventually" ? Seriously? Do you have any concept about how rare it
was to write anything at all (in Western Europe) before word spacing
became ubiquitous?

> and text with spaces is easier to read.

Oh, so you /do/ understand a little!

> That doesn't make text without spaces difficult to read.

Yes, it is /very/ hard to read. Try it.

> People work out complex
> and rather tendentious theories about why the ancients used Scriptio Continua
> and moderns use text separated by spaces.
>

Yes - people that are a lot smarter and more knowledgable than you, and
that don't have some bizarre agenda to try to "prove" that their unique
and illegible naming style is somehow better than what everyone else uses.

> You need to understand the strength of the simple, obvious argument, before you
> try to snipe at it with sophisticated objections.
>
> M.B. Parkes was my teacher at Oxford by the way. He taught me this stuff.

Appeal to authority again? Except this time you have picked an
"authority" that is meaningless to your audience, and who would probably
be horrified to hear what a jumbled mess you have made of his teachings,
and how you misuse your misunderstandings to justify bad coding (based
on the Wikipedia article and references).

On 27/08/2023 22:56, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 25/08/2023 20:59, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
> [...]
>>>> Any resolution here would place restrictions on which functions could
>>>> support named parameters - such as consistent declarations and
>>>> definitions, but it would be impossible (in general) to check them.
>>>
>>> Any parameter names in a call would just have to be consistent with
>>> the names in the visible prototype. I don't see a problem.
>>
>> You can have both "void foo(int a, int b);" and "void foo(int b, int
>> a);" declarations visible at the same time.
>
> So have a rule that the most recent declaration applies. If you write
> two declarations with deliberately misleading parameter names, you get
> what you deserve.
>
>> And if one translation unit defined "void foo(int a, int b);", while
>> another declared "void foo(int b, int a);" and used that with named
>> parameters, you would not get the correct call.
>
> True. So don't do that.

That would boil down to undiagnosable undefined behaviour - and I'd
rather avoid that. If there was a way to enforce checking here, it
would be significantly better (IMHO). To me, avoiding mistakes is the
most important justification for named parameters.

Since we can't do anything about currently legal declarations and
definitions with different (or missing) parameter names, I think we want
a new or modified syntax for the declaration and definition of functions
that can use named parameters. I think that with this new type of
declaration, the rules should be that a function should either be
"static" and have at most one forward declaration, or non-static and
have exactly one "extern" declaration in scope before it, and that the
parameter names and styles (such as pointers or array parameter) match
exactly. This would not force programmers to have declarations in a
single header that is included by both the defining TU and TU's that use
the function, but it would strongly encourage it. And it would make it
a lot harder to get wrong.

Since this would conflict with existing styles used in some code, I
think we'd need a new syntax (or a new function attribute or qualifier).
It's possible that compilers could have a flag to apply such checks by
default (gcc has "-Wmissing-declarations -Wredundant-declarations", but
no check on parameter names AFAIK), but that would be an implementation
option, useful to some people and not others.

>
>> If you required the compiler to enforce that all declarations and
>> definitions of a function used the same parameter names, then you'd do
>> much better. (There is still scope for errors, but would be basically
>> the same as we have today for calling functions with incorrect numbers
>> or types of arguments.) But that would conflict with existing code
>> that was valid before.
>
> I might have advocated requiring parameter names to be consistent
> (basically making parameter names as well as their types, part of the
> function signature), but it's too late for that.
>
>> So you'd need a new syntax to say that a function must have all its
>> declarations having consistent parameter names. You'd have to write
>> "void foo(int a static, int b static);" !
>
> No, I don't think you do.
>
> [...]
>

On Monday, 28 August 2023 at 09:40:00 UTC+1, David Brown wrote:
> On 28/08/2023 09:42, Malcolm McLean wrote:
>
> > People work out complex
> > and rather tendentious theories about why the ancients used Scriptio Continua
> > and moderns use text separated by spaces.
> >
> Yes - people that are a lot smarter and more knowledgable than you, and
> that don't have some bizarre agenda to try to "prove" that their unique
> and illegible naming style is somehow better than what everyone else uses.
>
> > You need to understand the strength of the simple, obvious argument, before you
> > try to snipe at it with sophisticated objections.
> >
>
A simple, straightforwards, obvious and natural point takes priority. Scriptio Continua
was used for 2000 years (first texts about 700 BC or so, the last texts 13th century
- I make that about 2000 years). So if it was difficut to read, would it have been
used for so long? Obviously not. People would have used dots or vertical lines,
both of which were used in very early Latin and Greek texts, and occasionally appear
in later manuscripts, but weren't very popular.

You have to learn how to draw conclusions from the information, not to trawl through
material looking for reasons to object to the obvious, because you are naturally
contentious in character.
>
> > M.B. Parkes was my teacher at Oxford by the way. He taught me this stuff.
>
> Appeal to authority again? Except this time you have picked an
> "authority" that is meaningless to your audience, and who would probably
> be horrified to hear what a jumbled mess you have made of his teachings,
> and how you misuse your misunderstandings to justify bad coding (based
> on the Wikipedia article and references).
>
Not really. When your old tutor's works come up, it's natural to mention that
he was your tutor.

On 28/08/2023 09:32, Malcolm McLean wrote:
> On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> No. Denis Ritchie didn't like const. But to say "const is a bad idea because
>>> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie
>>> almost certainly knows what he is talking about, and obvioulsy the committee
>>> has shown their inferiority inm many other ways. But you have to look at the
>>> arguments Ritchie used, not just say "Ritchie says so, so it is".
>> I am sorry, I am a bit lazy today and cannot be bothered to do web
>> searches. What exactly are Ritchie's arguments against "const"?
>>
>> I cannot think of any, but I have heard some that lend support
>> to having, and properly using, "const".
>>
> He write them in a leter tot he committee many years ago.
> I believe there was also apost to this newsgroup.
>
> His main focus of ire was "no alias", but he also criticised const.
>
> [Ritchie]
>
> Const has two virtues: putting things in read-only memory, and expressing interface restrictions.
> For example, saying
>
> char *strchr(const char *s, int c);
>
> is a reasonable way of expressing that the routine cannot change the
> object referred to by its first argument.
> I think that minor changes in wording preserve the virtues, yet
> eliminate the contradictions in the current scheme.
>
> [Malcolm]
> I think there's an element of politicing in agreeing to const in the last section. His real
> object is to get rid of noalias.So he throws the committe a sop. They can have const,
> with a few provisos.

It seems very clear to me from that letter that he found the concept of
"const" to be good and useful - but it needed some changes to the
wording in the standard and details of conversions involving "const".
He pointed out the well-known issues with "const" in functions like
"strchr" - but that "const" is useful despite being imperfect.

I see no indication that he is "throwing the committee a sop" - his
dislike of "noalias" is explicitly "non-negotiable", and entirely
independent of his other points.

Your interpretation of this letter is very strongly coloured by what you
wish it said, rather than what he actually wrote.