Named parameters

[Adam Ruth]

Hello,

Has there ever been any talk to adding named parameters to C? I enjoy
using them in my Python and Ada code and can see their usefulness in
C. I can envision an implementation where the naming would be based
upon a prototype and the parameter ordering could be worked out before
the linking phase (thus, no need to deal with changing a linker).

Just curious. I've done some googling and can't find any references,
but it is a bit of an obscure topic.

Thanks for the info,

Adam Ruth

[Jack Klein]

On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
comp.lang.c:

Hello,

Has there ever been any talk to adding named parameters to C? I enjoy
using them in my Python and Ada code and can see their usefulness in
C. I can envision an implementation where the naming would be based
upon a prototype and the parameter ordering could be worked out before
the linking phase (thus, no need to deal with changing a linker).

Just curious. I've done some googling and can't find any references,
but it is a bit of an obscure topic.

Thanks for the info,

Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely news:comp.std.c , which discusses the past, present,
and future ANSI/ISO/IEC standard for the language. It is not really
on-topic here, where the topic is the C language as it actually is.

There has never been much support for it in the past, and it would
break an enormous amount of existing code. Google for prior
discussions on comp.std.c.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Micah Cowan]

ow***@hotmail.c om (Adam Ruth) writes:

Hello,

Has there ever been any talk to adding named parameters to C? I enjoy
using them in my Python and Ada code and can see their usefulness in
C. I can envision an implementation where the naming would be based
upon a prototype and the parameter ordering could be worked out before
the linking phase (thus, no need to deal with changing a linker).

Thanks, but our parameters already *have* names :-) :-p

I'm assuming you mean something like where if you have the
prototype:

void foo(int bar, int baz, int quux);

Then you could call foo() as:

foo(baz = 15, quux = 42, bar = 32);

That is, in any order, provided they are named.

We actually already have something similar for initializers of
structs and arrays now, but I guess nobody cared enough about
using it for function calls. I don't really, either, FWIW. But I
wouldn't really be surprised to see them in a future version of
the Standard.

If you really want it, it wouldn't be extremely difficult to
write your own preprocessor which would translate such calls
appropriately. :-)

--
Micah J. Cowan
mi***@cowan.nam e

[Sheldon Simms]

On Thu, 30 Oct 2003 05:04:43 +0000, Jack Klein wrote:

On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
comp.lang.c:

Hello,

Has there ever been any talk to adding named parameters to C? I enjoy
using them in my Python and Ada code and can see their usefulness in
C. I can envision an implementation where the naming would be based
upon a prototype and the parameter ordering could be worked out before
the linking phase (thus, no need to deal with changing a linker).

Just curious. I've done some googling and can't find any references,
but it is a bit of an obscure topic.

Thanks for the info,

Adam Ruth

It has been discussed occasionally

There has never been much support for it in the past,
and it would break an enormous amount of existing code.

It wouldn't necessarily break any existing code. It is just
necessary to come up with a syntax for it that would be a
syntax error in C99. For example:

int foo (int bar, int baz) {
...
int main (void) {
...
return foo (baz:15, bar:-23);
}

With grammar changes:

argument-expression-list:
argument-expression
argument-expression-list "," argument-expression

argument-expression:
assignment-expression
identifier ":" assignment-expression
Whether it's particularly useful is another question. With
default arguments in the function definition, I think it
probably would be a nice to have.

-Sheldon

[Jack Klein]

On Thu, 30 Oct 2003 02:03:48 -0500, Sheldon Simms
<sh**********@y ahoo.com> wrote in comp.lang.c:

On Thu, 30 Oct 2003 05:04:43 +0000, Jack Klein wrote:

On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
comp.lang.c:

Hello,

Has there ever been any talk to adding named parameters to C? I enjoy
using them in my Python and Ada code and can see their usefulness in
C. I can envision an implementation where the naming would be based
upon a prototype and the parameter ordering could be worked out before
the linking phase (thus, no need to deal with changing a linker).

Just curious. I've done some googling and can't find any references,
but it is a bit of an obscure topic.

Thanks for the info,

Adam Ruth

It has been discussed occasionally

There has never been much support for it in the past,
and it would break an enormous amount of existing code.

It wouldn't necessarily break any existing code. It is just
necessary to come up with a syntax for it that would be a
syntax error in C99. For example:

int foo (int bar, int baz) {
...
int main (void) {
...
return foo (baz:15, bar:-23);
}

With grammar changes:

argument-expression-list:
argument-expression
argument-expression-list "," argument-expression

argument-expression:
assignment-expression
identifier ":" assignment-expression
Whether it's particularly useful is another question. With
default arguments in the function definition, I think it
probably would be a nice to have.

-Sheldon

That's not the problem, that's easy.

The real problem lies in the untold number of existing programs where
there is more than one prototype for the same function, with different
names.

Consider even, in one source file:

int func(int one, int two);

/* stuff */

int func(int two, int one)
{
/* ... */
return some_thing;
}

/* still later */

int otherfunc(void)
{
int x = /* whatever */;
int y = /* something else */;

int z = func(one:x, two:y);
}

Other than the named parameters in the call, the above is perfectly
legal C89 and C99.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Sheldon Simms]

On Thu, 30 Oct 2003 07:28:47 +0000, Jack Klein wrote:

On Thu, 30 Oct 2003 02:03:48 -0500, Sheldon Simms
<sh**********@y ahoo.com> wrote in comp.lang.c:

On Thu, 30 Oct 2003 05:04:43 +0000, Jack Klein wrote:

> On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
> comp.lang.c:
>
>> Has there ever been any talk to adding named parameters to C?
>
> It has been discussed occasionally
>
> There has never been much support for it in the past,
> and it would break an enormous amount of existing code.

It wouldn't necessarily break any existing code. It is just
necessary to come up with a syntax for it that would be a
syntax error in C99.

That's not the problem, that's easy.

The real problem lies in the untold number of existing programs where
there is more than one prototype for the same function, with different
names.

Consider even, in one source file:

int func(int one, int two);

/* stuff */

int func(int two, int one)
{
/* ... */
return some_thing;
}

/* still later */

int otherfunc(void)
{
int x = /* whatever */;
int y = /* something else */;

int z = func(one:x, two:y);
}

Other than the named parameters in the call, the above is perfectly
legal C89 and C99.

Well it's really only a problem if the same name is used for
different parameters in different prototypes and not enough
other named arguments are supplied for disambiguation (which
is obviously impossible in your example).

I can think of several solutions to the problem off the top of
my head. The most comprehensive would require augmenting the syntax
for parameter-declarations. The minimal would simply declare the use
of named parameters in that situation to be undefined behavior.
In between would be to associate the arguments with the actual
parameters according to the "last" prototype seen.

-Sheldon

[Dan Pop]

In <l6************ *************** *****@4ax.com> Jack Klein <ja*******@spam cop.net> writes:

On Thu, 30 Oct 2003 02:03:48 -0500, Sheldon Simms
<sh**********@ yahoo.com> wrote in comp.lang.c:

On Thu, 30 Oct 2003 05:04:43 +0000, Jack Klein wrote:

> There has never been much support for it in the past,
> and it would break an enormous amount of existing code.

Bullshit: it won't break any single piece of existing code, because
existing code doesn't use the (currently non-existing) feature.

Furthermore, I have yet to see a piece of C code where a function
declaration uses different parameter names than the function definition
(if the function declaration uses parameter names at all).

Any well written C program will contain exactly *one* declaration
and one definition for each global function it defines. Local functions
should have only the definition (except for the special case of
coroutines). More than that would create maintenance overheads.
It wouldn't necessarily break any existing code. It is just
necessary to come up with a syntax for it that would be a
syntax error in C99.

Exactly!
That's not the problem, that's easy.

The real problem lies in the untold number of existing programs where
there is more than one prototype for the same function, with different
names.

Non-issue: it is the one prototype that is currently in scope that
matters. The standard will simply have to specify which prototype is in
scope, if multiple prototypes are encountered: the first or the last.
Right now it doesn't matter, because the parameter names are ignored by
the compiler, only their types are relevant.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Adam Ruth]

Jack Klein <ja*******@spam cop.net> wrote in message news:<6r******* *************** **********@4ax. com>...

On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
comp.lang.c:

Hello,
[snip...]
Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely news:comp.std.c , which discusses the past, present,
and future ANSI/ISO/IEC standard for the language. It is not really
on-topic here, where the topic is the C language as it actually is.

I see the "this is off-topic" comment enough in this group to wonder
why that hasn't been put in the FAQ. Perhaps the name of the
newsgroup should change to be a bit more explicit about its topic.

[Joona I Palaste]

Adam Ruth <ow***@hotmail. com> scribbled the following:

Jack Klein <ja*******@spam cop.net> wrote in message news:<6r******* *************** **********@4ax. com>...

On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
comp.lang.c:

> Hello,
> [snip...]
> Adam Ruth
It has been discussed occasionally, on the newsgroup where it is
topical, namely news:comp.std.c , which discusses the past, present,
and future ANSI/ISO/IEC standard for the language. It is not really
on-topic here, where the topic is the C language as it actually is.

I see the "this is off-topic" comment enough in this group to wonder
why that hasn't been put in the FAQ. Perhaps the name of the
newsgroup should change to be a bit more explicit about its topic.

What, comp.lang.c isn't enough to tell you that this newsgroup is
about the computer language C?
Contrary to what people might think, comp.std.c is for the computer
standard about C, not the C defined in that standard.

It's really rather easy to figure out, once you grasp the idea that
Usenet newsgroup names are parsed in a strict left-to-right fashion.

comp: something about computers
comp.lang: something about computer languages
comp.lang.c: the computer language C

comp: something about computers
comp.std: something about computer standards
comp.std.c: the computer standard about C

***THE WRONG WAY!***
comp: something about computers
comp..c: something about the computer language C
comp.std.c: the C defined in the computer standard

See how the middle row skips over one part of the name and the bottom
row goes back to it? That's not how left-to-right parsing works.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You will be given the plague."
- Montgomery Burns

[Kevin Bracey]

In message <bn**********@o ravannahka.hels inki.fi>
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:

Adam Ruth <ow***@hotmail. com> scribbled the following:

Jack Klein <ja*******@spam cop.net> wrote in message news:<6r******* *************** **********@4ax. com>...

On 29 Oct 2003 19:35:21 -0800, ow***@hotmail.c om (Adam Ruth) wrote in
comp.lang.c:

> Hello,
> [snip...]
> Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely news:comp.std.c , which discusses the past, present,
and future ANSI/ISO/IEC standard for the language. It is not really
on-topic here, where the topic is the C language as it actually is.

I see the "this is off-topic" comment enough in this group to wonder
why that hasn't been put in the FAQ. Perhaps the name of the
newsgroup should change to be a bit more explicit about its topic.

What, comp.lang.c isn't enough to tell you that this newsgroup is
about the computer language C?

No need to get sarky.
It's really rather easy to figure out, once you grasp the idea that
Usenet newsgroup names are parsed in a strict left-to-right fashion.

comp: something about computers
comp.lang: something about computer languages
comp.lang.c: the computer language C

I think the point is that in the absence of an official charter, there
is an implicit ".iso-standard" at the end of "comp.lang. c", leaving anything
even vaguely system-specific or only partially portable without a home.
Most other comp.lang.* groups aren't that intolerant.

I mean, for example, what newsgroup would you discuss some detail of the EDG
compiler in? In the absence of a specific newsgroup, normal Usenet etiquette
would suggest comp.lang.c to be the closest match. My point is that it's no
use shouting "off-topic" at posters if you haven't got somewhere better for
them to go. And I don't really believe that more general groups like
"comp.programmi ng" are better for something that is C-related.

As for suggestions about things that could be added to C, surely it's
reasonable to start the discussion in comp.lang.c? It's not as though the
original poster was necessarily wanting to launch straight into the
standardisation process.

Sometimes I get the feeling that a lot of the regulars only come here to
be unpleasant to newcomers and score pedantry points off of each other.
More than the Usenet average, I mean. Couldn't we hive off all the pedantry
to comp.lang.c.sta ndard or something?

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/