Bart <bc@freeuk.com> writes:
[...]
> I assume the reason for the underscope (I don't know why there are two
> and not one), is so that 'str' is not shadowed by a global macro name
> 'str' if that happens to be defined before 'puts'.
>
> If 'str' expands to something that isn't an identifier, it can cause a
> syntax error.
>
> OK, use a prefix then, if the alternative is not to have the feature at all.

Those aren't the only alternatives.

> Note that somebody can still define a macro called 'puts'. Note also
> that gcc headers (that is, the headers that are associated with my gcc
> installation, in case somebody wants to bring that up again),

No, I don't want to bring that up again. Why do you?

> use
> "_Str" for the parameter name, with one underscore and a capital
> letter.
>
> It's not clear what the purpose of these names is, unless they had
> keyword parameters already in mind.

The purpose is conformance. A strictly conforming program can define
"str" as a macro before including <stdio.h>.

A program that defines "puts" as a macro before including <stdio.h> had
undefined behavior; see N1570 7.1.3p1, last bullet point. File scope
identifiers, including function names declared in standard headers, are
reserved for use a macro names. Parameter names are not.

[...]

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:

>> Not that either of these appeals to authority have any relevance.
>>
> You don't really understand the "authority" fallacy.
> Denis Ritchie's opinion that const was a bad idea doesn't make it true that
> const was a bad idea. His opinion that Coke is nicer than Pepsi would
> however make it true that Coke is nicer than Pepsi, for him.

So you cited DMR, the designer of the C language, simply as an example
of one person with a preference to avoid underscores in C identifiers?
It could have been Kevin from accounts or Barbara finance as neither
uses underscores in their C programs? In no way did you want to imply
that Ritchie's opinion as a highly respected programmer and the designer
of the language in question might carry greater weight (i.e. authority)
on this topic? Kevin, Barbara and DMR are all equally authoritative on
the matter of their own preferences. I find that hard to believe, but
if you /didn't/ intend an appeal to his (often presumed) authority, then
it was a very poor choice.

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.

But maybe you cited DMR simply because could not find any other
examples. I looked at your BBXRC code (I know it's not all yours) and I
found lots of identifiers with underscores:

only_saw_ascii_range
le_control_chars
be_control_chars
null_suggests_binary_
unexpected_null_threshold
even_null_threshold
TEXTENC_UTF8_BOM
TEXTENC_ANSI
utf16_unexpected_null_percent_
lodepng_decode32_file
error_exit
out_of_memory
opt_get

and so on. Are they your choices or someone else's?

--
Ben.

On 8/26/23 6:13 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/26/23 12:17 AM, Keith Thompson wrote:
> [...]
>>> Hmm. The standard could say that if you define a parameter name as
>>> an object-like macro before including a header that declares a
>>> function with that parameter, the behavior is undefined. In other
>>> words, standard parameter names would be reserved, but in fewer
>>> contexts than standard function names. Since parameter names are
>>> lowercase, there shouldn't be a lot of code using them as macros.
>>
>> Yes, they could, and break the backwards compatibility rule that has
>> been a fundamental rule for the history of the standard.
>
> No major edition of the standard has strictly followed that rule.
>
> `main() { printf("hello world); }` -- broken by C99
> `int restrict;` -- broken by C11
> `typedef int bool;` -- broken by C23
>
> And so on.

And each of those created debate, and was carefully considered.

The removal of implicit int in C99 was a deliberate decision, based on
the agreement that the "feature" was actually a bad idea, and it is easy
to fix the code, as you just need to add the int at the point where you
get the syntax error.

C11 reserving restrict was a single identifier, so limited impact on
programs. And again, should be simple to fix, as you will get a syntex
error. As I remember, there was a strong push from people working on
optimization, as it can have significant impact in some situations.

For bool, bool was added as a conditionally restricted name in C99, so
24 years later, code (that will be updated to C23) has almost certainly
removed other usage of the symbol.

It is a rule "proven" by the limited exceptions to it. The rule is to
take careful consideration of the breakage, not a total prohibition.

>
>> Yes, the common coding practice of UPPER CASE for macros limits the
>> damage, that common coding practice is NOT a "rule", so can't be
>> relied on.
>>
>> The problem is that there are people who don't follow that rule, and
>> their code could get broken.
>
> With carefully chosen parameter names, I'm skeptical that there's *any*
> existing code that would be broken.
>

I am not so sure. Yes, it will be rare, but not zero. More
problematically not sure you will always get a error if the header use
"user" names for parameters to be "pretty", and not implementation names
to be safe.

I suppose one option to make thing prettier would be to say that if the
prototype used a __ type name, that in the call, you are also allowed to
use a name without those two underscores (as long as that doesn't match
another parameter name).

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote:
>> >> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT)
>> >> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>> >> > Of course size_t has an underscore. Everyone knows that. And most people
>> >> > agree that it is horrible.
>> >> "Most people" meaning you made it up.
>> >>
>> > We could do a straw poll.
>> > How many people like the underscore in size_t and how many think it is
>> > horrible?
>> Did you really just set up a false dichotomy to try to tip the results?
>> The question should be simply whether you agree that it's horrible or
>> not. You don't have to actually like it to not agree that it's
>> horrible.
>>
> That's a mathematician thinking.

Thank you. But I don't really qualify anymore (I indeed I ever did).

And, in fact, I was actually thinking rhetorically -- how would I word
it to tip the result? I was considering: "is size_t a sound engineering
compromise or a dog's breakfast?".

> "Not horrible" is the complentary set to
> "horrible" and thus should be the other choice.
> It doesn't work like that.
> Bascially "horrible" is a word, whilst "not horrible" is not.

I refer you to David's excellent reply.

--
Ben.

Richard Damon <Richard@Damon-Family.org> writes:
> On 8/26/23 6:13 PM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 8/26/23 12:17 AM, Keith Thompson wrote:
>> [...]
>>>> Hmm. The standard could say that if you define a parameter name as
>>>> an object-like macro before including a header that declares a
>>>> function with that parameter, the behavior is undefined. In other
>>>> words, standard parameter names would be reserved, but in fewer
>>>> contexts than standard function names. Since parameter names are
>>>> lowercase, there shouldn't be a lot of code using them as macros.
>>>
>>> Yes, they could, and break the backwards compatibility rule that has
>>> been a fundamental rule for the history of the standard.
>> No major edition of the standard has strictly followed that rule.
>> `main() { printf("hello world); }` -- broken by C99
>> `int restrict;` -- broken by C11
>> `typedef int bool;` -- broken by C23
>> And so on.
>
> And each of those created debate, and was carefully considered.

As this should be.

[...]

>> With carefully chosen parameter names, I'm skeptical that there's
>> *any* existing code that would be broken.
>
> I am not so sure. Yes, it will be rare, but not zero. More
> problematically not sure you will always get a error if the header use
> "user" names for parameters to be "pretty", and not implementation
> names to be safe.

You'd get an error for a source file that defines a (lower case)
parameter name as a macro *before including the header*. How common is
that? (I'm guessing the most common case for that would be a
"-Dfoo=bar" command-line option.)

Suppose fopen's first parameter is named "filename". If I #define
filename after "#include <stdio.h>", that's fine. It only means that I
can't use a named argument when calling fopen -- but I've already
decided I want to use the identifier "filename" for my own purposes.

If there's real-world code that would break, either because it defines a
lowercase macro before including a standard header or because of
something I've missed, I'd be interested in seeing it.

> I suppose one option to make thing prettier would be to say that if
> the prototype used a __ type name, that in the call, you are also
> allowed to use a name without those two underscores (as long as that
> doesn't match another parameter name).

--
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 8/26/23 10:09 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/26/23 6:13 PM, Keith Thompson wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>> On 8/26/23 12:17 AM, Keith Thompson wrote:
>>> [...]
>>>>> Hmm. The standard could say that if you define a parameter name as
>>>>> an object-like macro before including a header that declares a
>>>>> function with that parameter, the behavior is undefined. In other
>>>>> words, standard parameter names would be reserved, but in fewer
>>>>> contexts than standard function names. Since parameter names are
>>>>> lowercase, there shouldn't be a lot of code using them as macros.
>>>>
>>>> Yes, they could, and break the backwards compatibility rule that has
>>>> been a fundamental rule for the history of the standard.
>>> No major edition of the standard has strictly followed that rule.
>>> `main() { printf("hello world); }` -- broken by C99
>>> `int restrict;` -- broken by C11
>>> `typedef int bool;` -- broken by C23
>>> And so on.
>>
>> And each of those created debate, and was carefully considered.
>
> As this should be.
>
> [...]
>
>>> With carefully chosen parameter names, I'm skeptical that there's
>>> *any* existing code that would be broken.
>>
>> I am not so sure. Yes, it will be rare, but not zero. More
>> problematically not sure you will always get a error if the header use
>> "user" names for parameters to be "pretty", and not implementation
>> names to be safe.
>
> You'd get an error for a source file that defines a (lower case)
> parameter name as a macro *before including the header*. How common is
> that? (I'm guessing the most common case for that would be a
> "-Dfoo=bar" command-line option.)

Yes, that is the most like case, a -D option, perhaps from an IDE
configuration.

>
> Suppose fopen's first parameter is named "filename". If I #define
> filename after "#include <stdio.h>", that's fine. It only means that I
> can't use a named argument when calling fopen -- but I've already
> decided I want to use the identifier "filename" for my own purposes.
>
> If there's real-world code that would break, either because it defines a
> lowercase macro before including a standard header or because of
> something I've missed, I'd be interested in seeing it.

I've seen code with lower case name macros as a result of converting run
time configuration to fixed configuration, provide at build time.

filename is a likely parameter for something like this.

>
>> I suppose one option to make thing prettier would be to say that if
>> the prototype used a __ type name, that in the call, you are also
>> allowed to use a name without those two underscores (as long as that
>> doesn't match another parameter name).
>

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

:)

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

On 8/26/2023 9:24 PM, 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);
>
> :)
>

fish:shark eats goat userid 42?

On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
> >> [...]
> >> >> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
> >> >> would be to call it "multiplymatrixwithvector".
> >> >>
> >> > Well Caesar disagreed.
> >> Let's drop the lengthy discussions of ancient writing systems, shall we?
> >> (And David, please stop encouraging them.)
> >>
> >For about two thousand years, text was written without spaces. Any rational
> >person, to whom this was pointed out, would accept that that is prima facie
> >evidence that it is not that difficult to read.
> 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?

On Saturday, 26 August 2023 at 18:31:21 UTC+1, David Brown wrote:
> On 26/08/2023 11:52, Malcolm McLean wrote:
> > On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
> >> [...]
> >>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
> >>>> would be to call it "multiplymatrixwithvector".
> >>>>
> >>> Well Caesar disagreed.
> >> Let's drop the lengthy discussions of ancient writing systems, shall we?
> >> (And David, please stop encouraging them.)
> >>
> > For about two thousand years, text was written without spaces. Any rational
> > person, to whom this was pointed out, would accept that that is prima facie
> > evidence that it is not that difficult to read. However David Brown has got to
> > try to make out that the reason the style was adopted was to make it harder
> > for slaves to read confidential documents. It's beyond absurd.
> I think I am beginning to understand. You can't read, or won't read, so
> it doesn't matter to you whether there are spaces or not.
>
> I enjoy talking about history, and I happen to know a bit about writing
> systems - modern and outdated. I had hoped, since you know a bit of
> Hebrew and have looked at old texts, that I might have learned something
> new. But I was wrong - you have some basic knowledge combined with some
> flat-earth ideas, and you haven't actually bothered reading what I
> wrote. So time to stop, I think.
>
I know. But it irritates Keith. And it's very tangential to C, so he has a case.

Text was written without spaces until the practice died out in the late medieval
period. It's not difficult to read, but silent reading was rare and most people
read aloud. Spaces make text easier for silent readers to read. Underscores -
the jury is out, but you can't simply assume that, because spaces make text
easier to read, underscores will also do so.

On 8/26/2023 11:08 PM, Malcolm McLean wrote:
> On Saturday, 26 August 2023 at 18:31:21 UTC+1, David Brown wrote:
>> On 26/08/2023 11:52, Malcolm McLean wrote:
>>> On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>>>> [...]
>>>>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>>>>>> would be to call it "multiplymatrixwithvector".
>>>>>>
>>>>> Well Caesar disagreed.
>>>> Let's drop the lengthy discussions of ancient writing systems, shall we?
>>>> (And David, please stop encouraging them.)
>>>>
>>> For about two thousand years, text was written without spaces. Any rational
>>> person, to whom this was pointed out, would accept that that is prima facie
>>> evidence that it is not that difficult to read. However David Brown has got to
>>> try to make out that the reason the style was adopted was to make it harder
>>> for slaves to read confidential documents. It's beyond absurd.
>> I think I am beginning to understand. You can't read, or won't read, so
>> it doesn't matter to you whether there are spaces or not.
>>
>> I enjoy talking about history, and I happen to know a bit about writing
>> systems - modern and outdated. I had hoped, since you know a bit of
>> Hebrew and have looked at old texts, that I might have learned something
>> new. But I was wrong - you have some basic knowledge combined with some
>> flat-earth ideas, and you haven't actually bothered reading what I
>> wrote. So time to stop, I think.
>>
> I know. But it irritates Keith. And it's very tangential to C, so he has a case.
>
> Text was written without spaces until the practice died out in the late medieval
> period. It's not difficult to read, but silent reading was rare and most people
> read aloud. Spaces make text easier for silent readers to read. Underscores -
> the jury is out, but you can't simply assume that, because spaces make text
> easier to read, underscores will also do so.
>

ever_use_posix_api_s ?

;^)

On Saturday, 26 August 2023 at 22:07:49 UTC+1, Richard Damon wrote:
> On 8/26/23 3:11 PM, Bart wrote:
>
> > Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have
> > parameter names, but they are 'filename' and 'mode'; I can't see any
> > underscores.
> Right, because currently, to document the function, since the names
> don't actually mean anything, they can use whatever is desired to
> document the behavior of the function.
>
> In fact, the name used in a prototype, if names are used at all, are
> meaningless to the actual function definition
>
Underscores make text hard to read. And the parameter name isn't part of
the standard. So when discussing the function, people use an easy-to-read
identifier, like "filename". If provided, the paramter name has to be surrounded
with underscores to put it into the implementation's namespace.
>
> > If so, /then/ what is the problem; that the names are ugly? That seems
> > to be par for the course for C's standard names.
> Yes, it says that to used named parameters to standard library
> functions, code would be filled with the "ugly" names.
>
That's a problem.
In fact if you said that code which #defined identifiers like "x" or "theta"
would invade implementation namespace, you would break very few
sanely written programs. But it would be a fairly big theoretical change.
But with the contract as it is, it's got to be __x or _X.

However named parameters aren't really a big help for standard library
functions. Most of them take only one or two parameters, and it's usually
easy to remember which is which. The one I can think of where it would
really help is qsort(), where it's not always easy to remember which is N
and which is width.
>
> > And it will be inefficient: structs are usually passed by reference to a
> > block of memory, so the arguments are not passed in registers.
> Depends on the API. some pass "small" structures in registers, so that
> could still work. If you have more than can be held in registers, it
> isn't that less efficent,
>
Microsoft use structures to pass large numbers of parameters to certain
functions, like ones to open a file dialog.
In reality I find that you wrap the call. You write a function which consists
of setting up the structure and assigning the fields, then calling the Microsoft
function.

KK> Quick, which one is the destination?
KK>
KK> strcpy(goat: userid, fish: uid);

I'm going to guess goat?

-----------------------------------
user is generated from /dev/urandom

On Sunday, 27 August 2023 at 00:45:02 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:
> >> Not that either of these appeals to authority have any relevance.
> >>
> > You don't really understand the "authority" fallacy.
> > Denis Ritchie's opinion that const was a bad idea doesn't make it true that
> > const was a bad idea. His opinion that Coke is nicer than Pepsi would
> > however make it true that Coke is nicer than Pepsi, for him.
>
> So you cited DMR, the designer of the C language, simply as an example
> of one person with a preference to avoid underscores in C identifiers?
>
>
DB
>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>> would be to call it "multiplymatrixwithvector".
>>
Malcolm
>Well Caesar disagreed.
>Denis Ritchie disagreed.
>Unfortunately I can't find it, but some reasearch on human-readable urls disagreed.

>Whilst all you can offer is "I disagree". But you automatically disagree with things
> some people say. So how much weight should we give to that?
>
Whist it is ultimately about something objective, because it's an objective statement
about human psychology, then "what everybody thinks" isn't a fallacy in the same way
that it would be if it were a claim about, for example, psychology.

Exceptions to David Brown's claim include Caesar, who would have written without
spaces, Denis Ritchie, who chose "isdigit" over is_digit, the url reasearchers I can't dig
out but I specifically remember the conclusion that hyphens made it easier for computers
to parse urls, but made it harder for humans,
>
> It could have been Kevin from accounts or Barbara finance as neither
> uses underscores in their C programs? In no way did you want to imply
> that Ritchie's opinion as a highly respected programmer and the designer
> of the language in question might carry greater weight (i.e. authority)
> on this topic? Kevin, Barbara and DMR are all equally authoritative on
> the matter of their own preferences. I find that hard to believe, but
> if you /didn't/ intend an appeal to his (often presumed) authority, then
> it was a very poor choice.
>
Its also a case that since Ritchie chose identifiers without underscores, then that
style continues, because his idnefiers are commonly seen in C source. (The point
David Brown only half understood).
But of course, yes, one of the reasons C was successful was that Ritchie was careful
in his choice of names. I do believe that people who came after have uglified things,
and done great damage to the language.
>
> 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.
>
> But maybe you cited DMR simply because could not find any other
> examples. I looked at your BBXRC code (I know it's not all yours) and I
> found lots of identifiers with underscores:
>
> only_saw_ascii_range
> le_control_chars
> be_control_chars
> null_suggests_binary_
> unexpected_null_threshold
> even_null_threshold
> TEXTENC_UTF8_BOM
> TEXTENC_ANSI
> utf16_unexpected_null_percent_
> lodepng_decode32_file
> error_exit
> out_of_memory
> opt_get
>
> and so on. Are they your choices or someone else's?
>
Some are my choices, some aren't.
BabyXRC is a standalone program which includes code from many sources,
(if you go to the webpages I attribute each file to the author). But it's not
primarily meant to be an API, so I'm not as careful in choices of interfaces
as with Baby X.
Baby X is const free, and uses the prefix bbx_ on all user-callable functions, except
for "startbabyx", and the prefix BBX_ for non-function-like macros and opaque pointers.
There's then a name in lower case, without underscores, for functions, whilst non-
functions are in all-caps.
Whilst it's not perfectly consistent (the UTF-8 functions take const char *s, for example)
it's pretty consistent, and it's designed with simplicity and ease of use as the top
priorty.
I use underscores to separate a prefix which isn't part of an English phrase, and
for a suffix like "_r" to indicate a recursive function.

I do use out_of_memory as a label very frequently. Fair point.

Then of course most of the time I don't work on my own projects. I work on code to
which other people contribute. And we have a house style, which is driven mainly by
the third party API, and capitalises each word. It's better to be consistent.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> However named parameters aren't really a big help for standard library
> functions. Most of them take only one or two parameters, and it's usually
> easy to remember which is which. The one I can think of where it would
> really help is qsort(), where it's not always easy to remember which is N
> and which is width.
[...]

Another example: the size and nmemb parameters of fread() and fwrite().

calloc() is almost another example, but the order of the arguments
doesn't actually matter.

--
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 Saturday, 26 August 2023 at 18:21:37 UTC+1, David Brown wrote:
> On 26/08/2023 11:55, Malcolm McLean wrote:
> > On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >>> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote:
> >>>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT)
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >>>>> Of course size_t has an underscore. Everyone knows that. And most people
> >>>>> agree that it is horrible.
> >>>> "Most people" meaning you made it up.
> >>>>
> >>> We could do a straw poll.
> >>> How many people like the underscore in size_t and how many think it is
> >>> horrible?
> >> Did you really just set up a false dichotomy to try to tip the results?
> >> The question should be simply whether you agree that it's horrible or
> >> not. You don't have to actually like it to not agree that it's
> >> horrible.
> >>
> > That's a mathematician thinking.
> Do you realise that this is a compliment? You write as though you meant
> it as criticism, but Ben's rational and logical thinking is a good thing
> - it's certainly far better than your politician "thinking".
> > "Not horrible" is the complentary set to
> > "horrible" and thus should be the other choice.
> No.
>
> The opposite of "think it is horrible" is "do not think it is horrible".
> It is not "think it is not horrible". But even that is vastly closer
> than "like it".
> > It doesn't work like that.
> I have no idea what you think "it" is, or how you think "it" might or
> might not work - but I strongly suspect you are wrong nonetheless.
> > Bascially "horrible" is a word, whilst "not horrible" is not.
> And the relevance of that is ... absolutely nothing.
>
>
> Please try again to answer Ben's question (or mine in an earlier post,
> which was much the same). Do you know what a false dichotomy is? Do
> you understand that your "straw poll" is a false dichotomy? Do you
> realise that false dichotomies are used to try to provoke an answer that
> appears to support a particular position, but does not represent a real
> model of viewpoints?
>
> Yes/no answers will do - but if you want to elaborate, please at least
> attempt to answer the questions.
>
Let's take probaly the most famous false dichotomy of all.
"Is it or is it not permissible to pay taxes to Caesar?"
According to Ben, this isn't a false dichotomy at all. Its either one or
the other.
But of course that's a totally inadequate way of looking at it.

Then take "who likes it"? In. Ben's world, there is a small class of people
in the "like" world, and a larger class of people who are not in this class,
but not in the "horrible" class either.
But yesterday my little niece said "I don't like dinosaurs".So was she saying
"I am not in the class of children who like dinosaurs?". Not really. What she
was saying was "I actively dislike dinosaurs. They offend me. Please take them
away."

Then as you yourself pointed out, there's a difference between thinking it
is "not horrible" and not thinking that it is horrible. Logically. But that's
hardly helpful.

There's far more to it than you think. If you were correct and language
worked like that, it would be easy to get computers to talk by applying a bit
of simple set theory. And of course that approach doesn't work.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> However named parameters aren't really a big help for standard library
> functions. Most of them take only one or two parameters, and it's usually
> easy to remember which is which. The one I can think of where it would
> really help is qsort(), where it's not always easy to remember which is N
> and which is width.

Also fread, fwrite and the largely forgotten bsearch. To make matters
worse, fread and fwrite go the other way to qsort and bsearch, and you
don't get any diagnostics since the types of the two counts are the
same. You might, for example, get the position of the 'end pointer'
argument to strtol wrong, but you'll usually get a warning about it.

--
Ben.

On 27/08/2023 12:05, Malcolm McLean wrote:
> On Saturday, 26 August 2023 at 18:21:37 UTC+1, David Brown wrote:
>> On 26/08/2023 11:55, Malcolm McLean wrote:
>>> On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote:
>>>>>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT)
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>>>>> Of course size_t has an underscore. Everyone knows that. And most people
>>>>>>> agree that it is horrible.
>>>>>> "Most people" meaning you made it up.
>>>>>>
>>>>> We could do a straw poll.
>>>>> How many people like the underscore in size_t and how many think it is
>>>>> horrible?
>>>> Did you really just set up a false dichotomy to try to tip the results?
>>>> The question should be simply whether you agree that it's horrible or
>>>> not. You don't have to actually like it to not agree that it's
>>>> horrible.
>>>>
>>> That's a mathematician thinking.
>> Do you realise that this is a compliment? You write as though you meant
>> it as criticism, but Ben's rational and logical thinking is a good thing
>> - it's certainly far better than your politician "thinking".
>>> "Not horrible" is the complentary set to
>>> "horrible" and thus should be the other choice.
>> No.
>>
>> The opposite of "think it is horrible" is "do not think it is horrible".
>> It is not "think it is not horrible". But even that is vastly closer
>> than "like it".
>>> It doesn't work like that.
>> I have no idea what you think "it" is, or how you think "it" might or
>> might not work - but I strongly suspect you are wrong nonetheless.
>>> Bascially "horrible" is a word, whilst "not horrible" is not.
>> And the relevance of that is ... absolutely nothing.
>>
>>
>> Please try again to answer Ben's question (or mine in an earlier post,
>> which was much the same). Do you know what a false dichotomy is? Do
>> you understand that your "straw poll" is a false dichotomy? Do you
>> realise that false dichotomies are used to try to provoke an answer that
>> appears to support a particular position, but does not represent a real
>> model of viewpoints?
>>
>> Yes/no answers will do - but if you want to elaborate, please at least
>> attempt to answer the questions.
>>
> Let's take probaly the most famous false dichotomy of all.

No, let's not. Let's try to answer the questions at hand. Should I
assume you can't answer them?

> "Is it or is it not permissible to pay taxes to Caesar?"
> According to Ben, this isn't a false dichotomy at all. Its either one or
> the other.

I haven't noticed Ben making any comment on that question. Would you
like to give a reference to his post? Or an accurate quotation?

And of course it has absolutely nothing to do with the fact that what
/you/ asked as your "straw poll" was absolutely and clearly a false
dichotomy.

> But of course that's a totally inadequate way of looking at it.
>
> Then take "who likes it"? In. Ben's world, there is a small class of people
> in the "like" world, and a larger class of people who are not in this class,
> but not in the "horrible" class either.

Again, you are inventing things that Ben did not say.

But /I/ said something to that effect. And since there are undoubtedly
three classes here (lots of people have put themselves in the "like"
group, you and Bart are in the "horrible" group, while Scott has, I
think, placed himself in the "don't care" group), then there is no doubt
that your question was a false dichotomy.

>
> There's far more to it than you think. If you were correct and language
> worked like that, it would be easy to get computers to talk by applying a bit
> of simple set theory. And of course that approach doesn't work.

Making vague and useless comments about how complicated human language
can be (as if it were something that you knew, and the rest of us do
not) does not let you off the hook for getting things wrong, trying to
con people with fallacious arguments, and being unable to own up to it.

On 27/08/2023 07:54, Malcolm McLean wrote:
> On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>>>> [...]
>>>>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>>>>>> would be to call it "multiplymatrixwithvector".
>>>>>>
>>>>> Well Caesar disagreed.
>>>> Let's drop the lengthy discussions of ancient writing systems, shall we?
>>>> (And David, please stop encouraging them.)
>>>>
>>> For about two thousand years, text was written without spaces. Any rational
>>> person, to whom this was pointed out, would accept that that is prima facie
>>> evidence that it is not that difficult to read.
>> 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.

That's a non-sequitur, as well as almost certainly a typo, making your
non-grammatical almost-sentence say the opposite of what you intended.

Wikipedia has a list of logical fallacies used in arguments. You've
gone through quite a few of them so far - are you trying to get them all
ticked off in one thread?

> Do you think that is remotely plausible?

Often, but certainly not always, things were written with the intention
of being read by the author.

This, of course, still applies today - much of what is written is notes
for your own benefit, thus it is not a problem that many people's
handwriting is practically illegible to others. Second on the list of
perspective readers is probably teachers, and third would be "nobody"
(we all know that most likely no one will ever really read the
documentation we write for our software). Writing things that are
actually read by anyone else has always been a minority of writing (even
though it is, obviously, a very important part of writing).

On 27/08/2023 08:08, Malcolm McLean wrote:
> On Saturday, 26 August 2023 at 18:31:21 UTC+1, David Brown wrote:

>> I enjoy talking about history, and I happen to know a bit about writing
>> systems - modern and outdated. I had hoped, since you know a bit of
>> Hebrew and have looked at old texts, that I might have learned something
>> new. But I was wrong - you have some basic knowledge combined with some
>> flat-earth ideas, and you haven't actually bothered reading what I
>> wrote. So time to stop, I think.
>>
> I know. But it irritates Keith. And it's very tangential to C, so he has a case.

I fully agree. I expect it annoys more than just Keith, though he is
often the one open enough to talk about it. So let's stop talking about it.

On 25/08/2023 20:59, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 25/08/2023 10:37, Malcolm McLean wrote:
>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
> [...]
>>>> There are good historical reasons for why named parameters are not
>>>> common in older languages, but are more common in newer ones. And there
>>>> are good technical reasons why they would be difficult to introduce to C
>>>> as an afterthought. But I agree with you that they can be helpful and
>>>> improve code readability, in languages that support them.
>>>>
>>> I don't really see what the technical problem is. The header would have to
>>> contain the names of the parameters (most do already). Then instead
>>> of putting parameter 1 into register a and parameter 2 into register b,
>>> the compiler matches them up. If its void foo(int x, int y) and the
>>> call is foo(y=1, x=2), then the compiler puts a 2 into register a and a 1
>>> into register b.
>>> I haven't tried to modify a compiler to do this so there might be something I
>>> haven't thought of. But it would be a fairly simple, contained change with no
>>> implications for the linker.
>>
>> The key technical problem for C is that the parameter names are not
>> part of the signature of the function. It is not uncommon for
>> declarations to have missing parameter names, or different names from
>> those uses in the definition of the function. (Sometimes there are
>> good reasons for this, sometimes it is laziness.) If a function is
>> defined as "void foo(int a, int b) { .. }", but the declaration used
>> to call it has "void foo(int b, int a);", then how should named
>> parameters be resolved?
>>
>> 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.

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.

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.

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

> Using the "name=value" syntax would conflict with the use of an
> assignment expression as an argument, so some new syntax would have to
> be invented.
>
> I know, we could reuse the "static" keyword! 8-)}
>
> [...]
>

On 26/08/2023 02:12, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/25/23 2:59 PM, Keith Thompson wrote:
> [...]
>>> 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. Using
>>> the "name=value" syntax would conflict with the use of an assignment
>>> expression as an argument, so some new syntax would have to be
>>> invented.
>>>
>>> I know, we could reuse the "static" keyword! 8-)}
>>> [...]
>>>
>>
>> As far as I know, C could still adopt the use of : for this purpose,
>> like Bart's language does.
>>
>> I can't think of anything that this would get confused with.
>
> Nor can I.
>
>> I think the biggest thing this would require is that every standard
>> library function would need to have the name used for its parameter
>> defined (or the standard say you can't portably use them with the
>> standard library functions.
>
> The standard already shows parameter names for library functions, though
> they're not currently semantically meaningful. If this feature were
> added in a future standard, the same names could be used.
>

The parameter names are not reserved identifiers - so someone could write:

#define s1 Surprise!
#define s2 This is going to cause trouble...

#include <string.h>

A declaration of "strcpy" that used parameter names "s1" and "s2" would
then be problematic.

I wonder if it would be possible for compilers to have a pre-processor
directive to turn off user-defined macros while processing system
headers? That would solve this issue. (It would probably be easier to
wait until the C++ has had some practice with modules and worked out the
kinks, then copy modules into C.)

>> I think the biggest issue there is that the names would need to be
>> somewhat ugle as they would need to be in the implementation reserved
>> namespace, as anything in the user namespace might be a macro
>
> I'm not sure that would be much of a problem. For example, given
> char *strcpy(char * restrict s1,
> const char * restrict s2);
> and a call like:
> strcpy(s1: foo, s2: bar);
> the lookup for the names s1 and s2 would refer only to the named
> parameters of the called function. If you define a macro "s1", you
> simply get whatever it expands to.
>
> Another issue is that library functions can additionally be defined as
> macros. One solution would be to say that if you use a named parameter
> association, it bypasses the macro and calls the function -- which could
> break some contrived macro invocations. Another would be to allow named
> parameter associations for macro invocations as well as function calls.
>

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

>> ... I looked at your BBXRC code (I know it's not all yours) and I
>> found lots of identifiers with underscores:
>>
>> only_saw_ascii_range
>> le_control_chars
>> be_control_chars
>> null_suggests_binary_
>> unexpected_null_threshold
>> even_null_threshold
>> TEXTENC_UTF8_BOM
>> TEXTENC_ANSI
>> utf16_unexpected_null_percent_
>> lodepng_decode32_file
>> error_exit
>> out_of_memory
>> opt_get
>>
>> and so on. Are they your choices or someone else's?
>>
> Some are my choices, some aren't.

It's odd (to me) that you chose /any/ since you are so sure they are a
bad idea for readability.

> Baby X is const free, and uses the prefix bbx_ on all user-callable
> functions,

You will note I did not pick any with a "bbx_" prefix because you had
explained that already. You have quite a collection of prefixes (bbx_,
xml_, opt_) as well as some sub-prefixes like utf8_. The result is a
fair few underscores.

> I use underscores to separate a prefix which isn't part of an English
> phrase, and for a suffix like "_r" to indicate a recursive function.

Why do you think they help with prefixes and suffixes but not also with
words? To me, both are uses are just separating parts.

> I do use out_of_memory as a label

.... and, it would appear, error_exit and parse_error. In fact I did not
see a label without an underscore.

> very frequently. Fair point.

Despite "knowing" that it's harder to read?

--
Ben.

On 26/08/2023 08:38, Malcolm McLean wrote:
> On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:
>>
>> Ritchie didn't use long identifiers much - and when he did, he used
>> underscores.
>>
> Here's some code by K and R. Either by Ritchie or agreed to by Ritchie.
>
> #include <stdio.h>
> #define MAXLINE 1000 /* maximum input line length */
> int getline(char line[], int max)
> int strindex(char source[], char searchfor[]);
> char pattern[] = "ould"; /* pattern to search for */
> /* find all lines matching pattern */
> main()
> {
> char line[MAXLINE];
> int found = 0;
> while (getline(line, MAXLINE) > 0)
> if (strindex(line, pattern) >= 0) {
> printf("%s", line);
> found++;
> }
> return found;
> }
> /* getline: get line into s, return length */
> int getline(char s[], int lim)
> {
> int c, i;
> i = 0;
> while (--lim > 0 && (c=getchar()) != EOF && c != '\n')
> s[i++] = c;
> if (c == '\n')
> s[i++] = c;
> s[i] = '\0';
> return i;
> }
> /* strindex: return index of t in s, -1 if none */
> int strindex(char s[], char t[])
> {
> int i, j, k;
> for (i = 0; s[i] != '\0'; i++) {
> for (j=i, k=0; t[k]!='\0' && s[j]==t[k]; j++, k++)
> 61
> ;
> if (k > 0 && t[k] == '\0')
> return i;
> }
> return -1;
> }
>
> You see quite clearly that the style used is to avoid underscores.

No, I see this style quite clearly fits exactly with the description I
gave. I see no evidence at all that the style used was avoiding
underscores - I only see evidence that in this piece of code, no
underscores were needed because all the identifiers were short. (It's
already been explained to you why identifiers were kept short in older
code.)

>>
>> Not that either of these appeals to authority have any relevance.
>>
> You don't really understand the "authority" fallacy.

Yes, I do. Perhaps you do too, but you failed to understand what you
wrote yourself and why it was an "appeal to authority" fallacy.

> Denis Ritchie's opinion that const was a bad idea doesn't make it true that
> const was a bad idea. His opinion that Coke is nicer than Pepsi would
> however make it true that Coke is nicer than Pepsi, for him.
>
> See the difference?

I understand that fine.

But you didn't discuss Ritchie's style to say what he personally
preferred (which is good, because you haven't the faintest idea what
style he would have preferred given modern tools and doing modern coding).

You brought up his style as justification for your insane theory that
underscores make long identifiers harder to read. /That/ was an appeal
to authority - and a silly one, since you had no evidence that your
authority agrees with you in this case.

Do /you/ see the difference?