On 25/08/2023 08:46, David Brown wrote:
> On 24/08/2023 16:50, Malcolm McLean wrote:

>> Languages that allow named parameters are nice, and if I was extending C
>> I would introduce that. The problem is that there are a few basic
>> mathematical
>> functions like tan() which are conventionally written tan(value), and
>> that was
>> then used a model for what other functions would be like. However only
>> a few
>> user-written functions calculate similar basic mathematical functions.
>> Generally it make sense to write payroll(employees=emp, Nemployees=N,
>> taxcode=1234), not payroll(emp, N, 1234);
>
> 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.

Which are?

>  But I agree with you that they can be helpful and
> improve code readability, in languages that support them.

Actually, when I call functions defined via a C header via my FFI, I can
apply keyword parameters if I want, /and/ define default values for
missing arguments. They don't need to be written in one of those languages.

So whereas in C I have to write this:

MessageBox(NULL, "Hello, World", "Caption", 0)

from one of my languages I can do this if I don't care what the caption is:

messagebox(message:"Hello, World")

The advantages:

* I don't need to remember exact capitalisation (this is thanks to case
insensitivity)

* I don't need to remember the number, position and default values of
every parameter (default values are not part of the sig anyway;
there, I need to read the spec to discover what don't-care values to
provide

With this one, I always have trouble remembering if the caption comes
before or after the main text.

* There is less clutter and less typing

* The call is self-documenting

The only downside is needing to know the names of the parameters.

You will probably say: a good IDE can help with some of this. I will
then say that this is another advantage:

* You don't need an advanced IDE; low-techs tool will work too. You can
even sketch out code with pencil and paper on a beach!

The point really is that it's funny that any C function can be used with
keyword parameters if defined via a binding in another suitable
language, but not from C itself.

---------------
clang func "MessageBoxA" (
ref void hwnd = nil,
ichar message, caption = "Caption",
u32 flags = 0)i32

Note that 'MessageBox' is an alias for MessageBoxA in both languages.

Malcolm McLean <malcolm.arthur.mclean@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?

I've never heard anyone but you complain about it.

Certainly the dozen or so people that participate in this thread
are hardly a representative sample.

I'd wager that most C programmers don't even think about it, much
less care.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Malcolm McLean <malcolm.arthur.mclean@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.)
>
>> Denis Ritchie disagreed.
>
>I doubt that. Dennis Ritchie worked in environments that limited
>external identifiers to 6 characters. That's why we have "strcpy",
>not because it's easier to read.

IIRC it was eight characters. The Oracle RDBMS when I worked on
it in the 90's limited all function names to 8 characters for
compatability with the older compilers/linkers. Which made for very
cryptic names.

v7 ld.c:

/* symbol management */
struct symbol {
char sname[8];
char stype;
char spare;
int svalue;
};

On Fri, 25 Aug 2023 14:06:09 +0000, Scott Lurndal wrote:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Malcolm McLean <malcolm.arthur.mclean@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.)
>>
>>> Denis Ritchie disagreed.
>>
>>I doubt that. Dennis Ritchie worked in environments that limited
>>external identifiers to 6 characters. That's why we have "strcpy",
>>not because it's easier to read.
>
> IIRC it was eight characters.

In Chapter 2 of K&R's "The C Programing Language" (1st edition),
the authors discuss the size of names:
"Only the first eight characters of an internal name are
significant, although more may be used. For external names,
such a function names and external variables, the number may
be less than eight, because external names are used by various
assemblers and loaders."

They go on to list (in Appendix A, "C Reference Manual") the
limits (by implementation) of external identifiers:
"DEC PDP-11 7 characters, 2 cases
Honeywell 6600 6 characters, 1 case
IBM 360/370 7 characters, 1 case
Interdata 8/32 8 characters, 2 cases"
and reiterate that
"No more than the first eight characters are significant,
although more may be used."

So, eight characters was the max for K&R C, with implementations
limiting it to less in many cases.

HTH
--
Lew Pitcher
"In Skills We Trust"

On 25/08/2023 15:49, Bart wrote:
> On 25/08/2023 08:46, David Brown wrote:
>> On 24/08/2023 16:50, Malcolm McLean wrote:
>
>>> Languages that allow named parameters are nice, and if I was extending C
>>> I would introduce that. The problem is that there are a few basic
>>> mathematical
>>> functions like tan() which are conventionally written tan(value), and
>>> that was
>>> then used a model for what other functions would be like. However
>>> only a few
>>> user-written functions calculate similar basic mathematical functions.
>>> Generally it make sense to write payroll(employees=emp, Nemployees=N,
>>> taxcode=1234), not payroll(emp, N, 1234);
>>
>> 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.
>
> Which are?

They were not common in older languages because they make the compiler
more complicated, and enforcing them means you need more information
communicated between modules than you get with just a function name in
an assembly file or object file. Thus you need a real "module" system,
which is lacking in C.

They are common in newer languages because they are useful, and we have
fewer limitations on things like compiler sizes and complexity, and can
be more flexible about modules and file formats.

The key technical issue for making it an add-on to C is that C function
declarations and definitions can have different parameter names (see my
other reply on this one).

>
>>   But I agree with you that they can be helpful and improve code
>> readability, in languages that support them.
>
> Actually, when I call functions defined via a C header via my FFI, I can
> apply keyword parameters if I want, /and/ define default values for
> missing arguments. They don't need to be written in one of those languages.
>

Yes, that would seem reasonable - you have a wrapper in your own
language, and use whatever features your own language supports.

> So whereas in C I have to write this:
>
>     MessageBox(NULL, "Hello, World", "Caption", 0)
>
> from one of my languages I can do this if I don't care what the caption is:
>
>     messagebox(message:"Hello, World")
>
> The advantages:
>
> * I don't need to remember exact capitalisation (this is thanks to case
>   insensitivity)

(That is not an advantage, IMHO - it is a disadvantage. But let's not
get into that again - certainly it makes sense for the wrappers to use
the same conventions as the rest of your language, not the conventions
of the language being called.)

>
> * I don't need to remember the number, position and default values of
>   every parameter (default values are not part of the sig anyway;
>   there, I need to read the spec to discover what don't-care values to
>   provide
>
>   With this one, I always have trouble remembering if the caption comes
>   before or after the main text.

Yes, that's the point of named parameters.

>
> * There is less clutter and less typing

Named parameters are /more/ typing, not less - but it is useful
additional typing.

>
> * The call is self-documenting

Ha! The myth of self-documenting code never dies - every programmer of
every language thinks their own code is so clear it doesn't need
additional documentation.

But named parameters can certainly make code less cryptic.

>
> The only downside is needing to know the names of the parameters.
>
> You will probably say: a good IDE can help with some of this.

I wasn't going to say it, but it is true :-)

> I will
> then say that this is another advantage:
>
> * You don't need an advanced IDE; low-techs tool will work too. You can
>   even sketch out code with pencil and paper on a beach!

I agree - you don't /need/ a good IDE for any programming. But often it
helps.

>
> The point really is that it's funny that any C function can be used with
> keyword parameters if defined via a binding in another suitable
> language, but not from C itself.

That's not remotely surprising.

But to be clear, I think it's nice that you support named parameters in
your language.

>
> ---------------
> clang func "MessageBoxA" (
>     ref void hwnd = nil,
>     ichar message, caption = "Caption",
>     u32 flags = 0)i32
>
> Note that 'MessageBox' is an alias for MessageBoxA in both languages.

On 2023-08-25, David Brown <david.brown@hesbynett.no> wrote:
> On 25/08/2023 15:49, Bart wrote:
>> On 25/08/2023 08:46, David Brown wrote:
>>> On 24/08/2023 16:50, Malcolm McLean 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.
>>
>> Which are?
>
> They were not common in older languages because they make the compiler
> more complicated, and enforcing them means you need more information
> communicated between modules than you get with just a function name in
> an assembly file or object file. Thus you need a real "module" system,
> which is lacking in C.

Namde parameters are not common in older languages, because it
didn't occur to people at the time.

Functions are inspired by mathematics, and you don't encounter
anything like named parameters in common math. It's always f(a, b)
not f(x: a, y: b).

Even if you hit upon the idea, it's not obvious that it's an
improvement.

You need to have had experience working in very large code bases
with vast numbers of API's with mixed conventions.

Even then, you might not find named arguments appealing due to the
verbosity.

You might not find naed arguments appealing due to real technical
issues too.

Suppose you have a language in which the model of a function call
is that "expressions are evaluated in left to right order (or right to
left) and pushed on the stack in that order".

If you throw in named arguments into the mix, what happens to
the eval order? Do you preserve the written order, or do you
transform the function call according to the names into the function
call that doesn't use names?

Preserving the written order means temporary variables: you need a
better compiler to eliminate them. Rearranging the order to match
the underlying positiona argument order leads to surprising
behaviors when the argument expressions have side effects.

Specifically in C, we don't have a required evaluation order. But
still, typically, it has been historically predictable in specific
compilers.

Speaking of layering, there is the fact that the underlying function
call mechanism does not itself use the names. (There are languages
with keyword arguments, like Common Lisp and Python, where the
callee receives the keywords; I'm not writing about that.)

The named arguments are transformed a function call which just passes
the arguents by position.

So any way you look at it, named arguments are an extra layer of fluff
that is optional, and that is firmly understood in terms of a function
call without named parameters.

Named arguments can lead to the following unintended harm.
Regular, unnamed positional arguments tend to discourage the
proliferation of API's with large numbers of parameters.

With named parameters (especially if some parameters can be optional)
it's possible to abandon the pressure to reduce the number of
parameters that makes for better API design.

The named arguments become the API, and that API is no longer workable
without named arguments.

> The key technical issue for making it an add-on to C is that C function
> declarations and definitions can have different parameter names (see my
> other reply on this one).

That is actually fine because the caller would just use the declaration
that it has. It's just as syntactic sugar that plays out at the call
site, that the callee has no knowledge about.

When a function is redeclared, the names could be composed together
as follows: if both declarations name a parameter, the most recent
one wins. If only one of them names the parameter, that is the name.

Here is the problem: if duplicat names result, it is a diagnosable
error, e.g.:

void foo(int x, int);

void foo(int, int x);

Since this is currently valid code, the rule would probably have to be
that the most recent declaration completely replaces the name list; the
name of the leftmost parameter becomes unavailable due to the second
redeclaration.

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

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Fri, 25 Aug 2023 14:06:09 +0000, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>Malcolm McLean <malcolm.arthur.mclean@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.)
>>>
>>>> Denis Ritchie disagreed.
>>>
>>>I doubt that. Dennis Ritchie worked in environments that limited
>>>external identifiers to 6 characters. That's why we have "strcpy",
>>>not because it's easier to read.
>>
>> IIRC it was eight characters.
>
> In Chapter 2 of K&R's "The C Programing Language" (1st edition),
> the authors discuss the size of names:
> "Only the first eight characters of an internal name are
> significant, although more may be used. For external names,
> such a function names and external variables, the number may
> be less than eight, because external names are used by various
> assemblers and loaders."
>
> They go on to list (in Appendix A, "C Reference Manual") the
> limits (by implementation) of external identifiers:
> "DEC PDP-11 7 characters, 2 cases
> Honeywell 6600 6 characters, 1 case
> IBM 360/370 7 characters, 1 case
> Interdata 8/32 8 characters, 2 cases"
> and reiterate that
> "No more than the first eight characters are significant,
> although more may be used."
>
> So, eight characters was the max for K&R C, with implementations
> limiting it to less in many cases.

For K&R C, the limit was 8 for *internal* identifiers. The limit for
external identifiers (like strcpy) was what we'd now call
implementation-defined, with at least one implementation imposing a
limit of 6 (and not distinguishing between foobar and FOOBAR).

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

--
Ben.

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.

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

[...]

--
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 Fri, 25 Aug 2023 11:45:24 -0700, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Fri, 25 Aug 2023 14:06:09 +0000, Scott Lurndal wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>Malcolm McLean <malcolm.arthur.mclean@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.)
>>>>
>>>>> Denis Ritchie disagreed.
>>>>
>>>>I doubt that. Dennis Ritchie worked in environments that limited
>>>>external identifiers to 6 characters. That's why we have "strcpy",
>>>>not because it's easier to read.
>>>
>>> IIRC it was eight characters.
>>
>> In Chapter 2 of K&R's "The C Programing Language" (1st edition),
>> the authors discuss the size of names:
>> "Only the first eight characters of an internal name are
>> significant, although more may be used. For external names,
>> such a function names and external variables, the number may
>> be less than eight, because external names are used by various
>> assemblers and loaders."
>>
>> They go on to list (in Appendix A, "C Reference Manual") the
>> limits (by implementation) of external identifiers:
>> "DEC PDP-11 7 characters, 2 cases
>> Honeywell 6600 6 characters, 1 case
>> IBM 360/370 7 characters, 1 case
>> Interdata 8/32 8 characters, 2 cases"
>> and reiterate that
>> "No more than the first eight characters are significant,
>> although more may be used."
>>
>> So, eight characters was the max for K&R C, with implementations
>> limiting it to less in many cases.
>
> For K&R C, the limit was 8 for *internal* identifiers.

I believe that the limit was 8 for /all/ identifiers, with two caveats
1) names could be longer, but only the first 8 characters were
significant, and
2) extern identifiers were often limited by the operating environment
(likely the limits of the assembler[1] or linker) to less than the 8
significant characters that the parser recognized.

> The limit for
> external identifiers (like strcpy) was what we'd now call
> implementation-defined, with at least one implementation imposing a
> limit of 6 (and not distinguishing between foobar and FOOBAR).

While I agree that the length of extern identifiers would have been
called "implementation defined", I don't think that the lengths could
exceed the 8 significant character maximum imposed by the compiler.
In other words, a K&R C compiler wouldn't allow (for instance) a 10
significant character extern identifier.

[1] Section 2.1 "Identifiers" of the "UNIX Assembler Reference Manual"
says that
"An identifier consists of a sequence of alphanumeric characters
... of which the first may not be numeric. Only the first eight
characters are significant."
The toolchain was source -> compile -> assemble -> link -> binary
and the assembler was (and usually still is) a critical part of
that chain. If the /assembler/ limits labels to 8 significant
characters, then the language has to either accomodate that
limitation, or find a kluge around it. It looks like Ritchie
et al stuck with the assembler limits here.

Just my 2 cents worth.
--
Lew Pitcher
"In Skills We Trust"

On 8/25/23 2:59 PM, 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.
>
> 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.

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.

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

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.

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

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

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

Or, if you implement it for macros, you don't need to implement it for
functions. It's probably best to do both, but one can image a trial
implementation using just the pre-processor.

--
Ben.

On 26/08/2023 00:34, Richard Damon wrote:
> On 8/25/23 2:59 PM, 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.
>>
>> 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.

"." is already used by C for designated initialisers for structs. Why
not just use that?

>
> I can't think of anything that this would get confused with.
>
> 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.
>
> 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

So, if a function uses x and y parameters, they can clash with
user-defined macros called 'x' and 'y'?

But, this is already going to be a problem with arbitrarily named
functions in a library, plus variables, types, enums and macros exported
from that library.

If every such parameter name is to be uglified, then there seems little
point.

One possible answer might be a new kind of token which is
".alphanumeric", where the alphanumeric part is not checked for macro
expansion.

BTW I hadn't considered the macro angle. I tried the example below (in
my language), and it worked as expected, but then my macros are expanded
at a later stage than in C, so in the context of the keyword:value pair
'x:37', 'x' is a not a candidate for expansion.

A potentially bigger problem in C is how to deal with default parameter
values which is an essential part of keyword parameters. Especially
regarding the lexical scope of the names used in the default value
expression.

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

macro x=999

proc bill(int x=10)=
println x
end

proc main=
bill() # output 10
bill(x:37) # output 37
bill(x) # output 999
bill(x:x) # output 999
end

Bart <bc@freeuk.com> writes:
> On 26/08/2023 00:34, Richard Damon wrote:
[...]
>> As far as I know, C could still adopt the use of : for this purpose,
>> like Bart's language does.
>
> "." is already used by C for designated initialisers for structs. Why
> not just use that?

It would probably work, but I dislike it. In a designated initializer,
the ".foo = 42" syntax mirrors the "obj.foo" syntax for referring to a
member of a struct object, just as "[0] = 42" mirrors the "obj[0]"
syntax.

Using ":" IMHO looks nice, and doesn't clash with anything else.

Ada uses "=>", which could also work. (Python uses "=", which it can do
because it doesn't use "=" for assignment expressions.)

Not a huge deal either way.

For that matter, a future C *could* use "=" as long as it disallowed
assigment expressions as arguments. That would be in some sense
cleaner, since it would suggest the assignment of an argument value to a
parameter, but it would break some existing code, and could even change
the meaning of some code that's currently valid but contrived.

[...]

> One possible answer might be a new kind of token which is
> ".alphanumeric", where the alphanumeric part is not checked for macro
> expansion.

But ".alphanumeric" is already two tokens that can appear together.

[...]

--
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/25/23 8:12 PM, 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.
>
>> 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.
>

The problem would be needing to completely throw out the existing phases
of translation.

For instance, a translation unit is allowed to have defined something like:

#define s1 x+y(

before including the system headers. so to ignore that macro in that
context, would need a complete change in how the preprocessor works.

The fact that s1 is in the user namespace says the header can't actually
have used that name.

This is why actual headers are filled with names that begin with underscores

On 8/25/23 9:16 PM, Bart wrote:
> On 26/08/2023 00:34, Richard Damon wrote:
>> On 8/25/23 2:59 PM, 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.
>>>
>>> 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.
>
> "." is already used by C for designated initialisers for structs. Why
> not just use that?

That could work too.

It still have the macro problem (at least for standard headers)

>
>>
>> I can't think of anything that this would get confused with.
>>
>> 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.
>>
>> 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
>
> So, if a function uses x and y parameters, they can clash with
> user-defined macros called 'x' and 'y'?

Of course, C macros are global substitutes.

>
> But, this is already going to be a problem with arbitrarily named
> functions in a library, plus variables, types, enums and macros exported
> from that library.

If the header defines that the indentifies are reserved for its us, then
the user code won't (or shouldn't) define macros for them.

>
> If every such parameter name is to be uglified, then there seems little
> point.

Yes, that was my point for system headers. You would need something like:

strcpy(_Src: p1, _Dst: p2);

since those are reserved names for the implementation.

>
> One possible answer might be a new kind of token which is
> ".alphanumeric", where the alphanumeric part is not checked for macro
> expansion.

except that would impact something like x.y where you may WANT to have a
macro for the y part.

>
>
> BTW I hadn't considered the macro angle. I tried the example below (in
> my language), and it worked as expected, but then my macros are expanded
> at a later stage than in C, so in the context of the keyword:value pair
> 'x:37', 'x' is a not a candidate for expansion.
>
> A potentially bigger problem in C is how to deal with default parameter
> values which is an essential part of keyword parameters. Especially
> regarding the lexical scope of the names used in the default value
> expression.
>
> -----------------------------
>
>     macro x=999
>
>     proc bill(int x=10)=
>         println x
>     end
>
>     proc main=
>         bill()                # output 10
>         bill(x:37)            # output 37
>         bill(x)               # output 999
>         bill(x:x)             # output 999
>     end
>
>

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.)
>
> > Denis Ritchie disagreed.
>
> I doubt that. Dennis Ritchie worked in environments that limited
> external identifiers to 6 characters. That's why we have "strcpy",
> not because it's easier to read.
>
However that's not the explanation for isdigit() rather than is_digit().

Malcolm McLean <malcolm.arthur.mclean@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.)
>>
>> > Denis Ritchie disagreed.
>>
>> I doubt that. Dennis Ritchie worked in environments that limited
>> external identifiers to 6 characters. That's why we have "strcpy",
>> not because it's easier to read.
>>
> However that's not the explanation for isdigit() rather than is_digit().

I should have said 6 *significant* characters, so is_digit and
is_digest might be treated as the same identifier. The early limits
on external identifiers forced terse names for library functions.
Adding underscores for only some function names would not have been
helpful. (I haven't checked whether any standard library function
names in C90 have underscores, because I don't care that much.)

--
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 Damon <Richard@Damon-Family.org> writes:
> On 8/25/23 8:12 PM, Keith Thompson wrote:
[...]
>> 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.
>
> The problem would be needing to completely throw out the existing
> phases of translation.
>
> For instance, a translation unit is allowed to have defined something like:
>
> #define s1 x+y(
>
> before including the system headers. so to ignore that macro in that
> context, would need a complete change in how the preprocessor works.
>
> The fact that s1 is in the user namespace says the header can't
> actually have used that name.
>
> This is why actual headers are filled with names that begin with underscores

My suggestion is that if you define s1 as a macro, something like
strcpy(s1: dst, s2: src);
would simply expand the macro, and very likely fail to compile. I don't
think it's likely to be a problem in practice. No existing code uses
the new feature, so in that sense it would be backward compatible.

--
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 Friday, 25 August 2023 at 14:49:23 UTC+1, Bart wrote:
> On 25/08/2023 08:46, David Brown wrote:
> > On 24/08/2023 16:50, Malcolm McLean wrote:
>
> >> Languages that allow named parameters are nice, and if I was extending C
> >> I would introduce that. The problem is that there are a few basic
> >> mathematical
> >> functions like tan() which are conventionally written tan(value), and
> >> that was
> >> then used a model for what other functions would be like. However only
> >> a few
> >> user-written functions calculate similar basic mathematical functions.
> >> Generally it make sense to write payroll(employees=emp, Nemployees=N,
> >> taxcode=1234), not payroll(emp, N, 1234);
> >
> > 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.
> Which are?

Thank you. You actually write compilers.

On 8/25/23 10:58 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/25/23 8:12 PM, Keith Thompson wrote:
> [...]
>>> 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.
>>
>> The problem would be needing to completely throw out the existing
>> phases of translation.
>>
>> For instance, a translation unit is allowed to have defined something like:
>>
>> #define s1 x+y(
>>
>> before including the system headers. so to ignore that macro in that
>> context, would need a complete change in how the preprocessor works.
>>
>> The fact that s1 is in the user namespace says the header can't
>> actually have used that name.
>>
>> This is why actual headers are filled with names that begin with underscores
>
> My suggestion is that if you define s1 as a macro, something like
> strcpy(s1: dst, s2: src);
> would simply expand the macro, and very likely fail to compile. I don't
> think it's likely to be a problem in practice. No existing code uses
> the new feature, so in that sense it would be backward compatible.
>

The problem is that the standard way the system header is defined, is
that it will also use that name, and the system header won't compile,
which isn't conforming behavior.

While the implementtion doesn't need to store the system headers as
normal include files, it is a very common way to define them.

On Saturday, 26 August 2023 at 02:16:48 UTC+1, Bart wrote:
>
> > 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
> So, if a function uses x and y parameters, they can clash with
> user-defined macros called 'x' and 'y'?
>
Yes. The problem is this.

/* foo.h */
void foo(int x);

#define x 100
#include "foo.h"

It's unlikely that anyone would be so stupid as to #define x, but other parameter
names, such as "Nelements", might clash with symbols someone would want to
use.
To get round this problem, some people omit parameter names from headers in
the prototype.
void foo(int)

Of course if you do this in user code then it is a complete nightmare, because
someone reading the code then. has no clue what the parameters mean.

On Saturday, 26 August 2023 at 03:55:53 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > However that's not the explanation for isdigit() rather than is_digit().
> I should have said 6 *significant* characters, so is_digit and
> is_digest might be treated as the same identifier. The early limits
> on external identifiers forced terse names for library functions.
> Adding underscores for only some function names would not have been
> helpful. (I haven't checked whether any standard library function
> names in C90 have underscores, because I don't care that much.)
>
What I said to David Brown was that standard library functions were the
most commonly called functions in C code, and were all written in the
style I am recommending. He responded by pointing out that some
rarely used non-function identiifers, not I think in Ritchie's original
version of C, have underscores. So only half understanding the point.

Underscores have been introduced for a handful of new time and date
fucntions which have "restart" options, indicated y a "_r" suffix.

Terseness due to the limitations of compilers and linkers at the time
is part of the explanation, of course. But it could easily have been
is_digit() rather than "isdigit", and my point stands.

Richard Damon <Richard@Damon-Family.org> writes:
> On 8/25/23 10:58 PM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 8/25/23 8:12 PM, Keith Thompson wrote:
>> [...]
>>>> 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.
>>>
>>> The problem would be needing to completely throw out the existing
>>> phases of translation.
>>>
>>> For instance, a translation unit is allowed to have defined something like:
>>>
>>> #define s1 x+y(
>>>
>>> before including the system headers. so to ignore that macro in that
>>> context, would need a complete change in how the preprocessor works.
>>>
>>> The fact that s1 is in the user namespace says the header can't
>>> actually have used that name.
>>>
>>> This is why actual headers are filled with names that begin with underscores
>> My suggestion is that if you define s1 as a macro, something like
>> strcpy(s1: dst, s2: src);
>> would simply expand the macro, and very likely fail to compile. I don't
>> think it's likely to be a problem in practice. No existing code uses
>> the new feature, so in that sense it would be backward compatible.
>>
>
> The problem is that the standard way the system header is defined, is
> that it will also use that name, and the system header won't compile,
> which isn't conforming behavior.
>
> While the implementtion doesn't need to store the system headers as
> normal include files, it is a very common way to define them.

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.

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