Named parameters

A

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
 
J

Jack Klein

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 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.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
M

Micah Cowan

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. :)
 
S

Sheldon Simms

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
 
J

Jack Klein

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.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
S

Sheldon Simms

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
 
D

Dan Pop

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

Adam Ruth

Jack Klein said:
Hello,
[snip...]
Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely 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.
 
J

Joona I Palaste

Adam Ruth said:
Jack Klein said:
Hello,
[snip...]
Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely 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.
 
K

Kevin Bracey

In message <[email protected]>
Joona I Palaste said:
Adam Ruth said:
Jack Klein said:
On 29 Oct 2003 19:35:21 -0800, (e-mail address removed) (Adam Ruth) wrote in
comp.lang.c:

Hello,
[snip...]
Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely 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.programming" 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.standard or something?
 
T

Thomas Stegen

Joona said:
Adam Ruth <[email protected]> scribbled the following:


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

You might be interested to know that comp.lang.c is an exception to
the rule. Maybe looking at some other language groups might be of help.

Besides, I think the OP was perfectly on topic.
 
I

Irrwahn Grausewitz

Thomas Stegen said:
You might be interested to know that comp.lang.c is an exception to
the rule. Maybe looking at some other language groups might be of help.

Besides, I think the OP was perfectly on topic.

Not really. He should have posted his question to comp.std.c,
as has already been pointed out upthread.

Regards
 
A

Adam Ruth

Joona I Palaste said:
Adam Ruth said:
Jack Klein said:
On 29 Oct 2003 19:35:21 -0800, (e-mail address removed) (Adam Ruth) wrote in
comp.lang.c:

Hello,
[snip...]
Adam Ruth

It has been discussed occasionally, on the newsgroup where it is
topical, namely 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.

What is it about the name comp.lang.c that excludes my question? The
fact that there's another newsgroup that *may* be more germaine? Must
I fully grok in minute detail the "topic" of every newsgroup available
before I make a decision where to post?

What makes you think my question was about standards anyway? I ask a
question "Has there ever been talk of adding named parameters to C?"
and suddenly I'm shunted off to a standards newsgroup? My question is
plainly about C in it's most generic sense, even though an answer may
include reference to the standard. I think it's bogus to say that
this group is about what C *is*, because there are many Cs: Past,
present, and future. Not to mention the many non-standard versions
and extensions. Where better to discuss all of these incarnations in
one place?

The response I got, "It is not really on-topic here, where the topic
is the C language as it actually is." while not being rude wasn't very
polite either. If my question really was off-topic, a
characterization I dispute, then a polite response might be, "You
would probably get a better answer in comp.std.c, we don't really
discuss those issues much here.".

Just my $2/100. Is it too off topic to discuss the topic of the
newsgroup? I hope not.

Adam Ruth
 
A

Adam Ruth

Irrwahn Grausewitz said:
Not really. He should have posted his question to comp.std.c,
as has already been pointed out upthread.

Regards

Why? It wasn't a question about standard C, it was a question about C.
 
I

Irrwahn Grausewitz

Why? It wasn't a question about standard C, it was a question about C.

Because:

- questions about 'pure' standard (ISO) C are topical in comp.lang.c
- questions about the C (ISO) standard are topical in comp.std.c
- questions about C plus non-standard/implementation-dependent
extensions to the language are topical in newsgroups dedicated to
these extensions/implementations. If there is no such group, there is
still comp.programming.

HTH
Regards
 
P

pete

Adam Ruth wrote:
What is it about the name comp.lang.c that excludes my question? The
fact that there's another newsgroup that *may* be more germaine? Must
I fully grok in minute detail the "topic" of every newsgroup available
before I make a decision where to post?

What makes you think my question was about standards anyway? I ask a
question "Has there ever been talk of adding named parameters to C?"
and suddenly I'm shunted off to a standards newsgroup? My question is
plainly about C in it's most generic sense, even though an answer may
include reference to the standard. I think it's bogus to say that
this group is about what C *is*, because there are many Cs: Past,
present, and future. Not to mention the many non-standard versions
and extensions. Where better to discuss all of these incarnations in
one place?

The response I got, "It is not really on-topic here, where the topic
is the C language as it actually is." while not being rude wasn't very
polite either. If my question really was off-topic, a
characterization I dispute, then a polite response might be, "You
would probably get a better answer in comp.std.c, we don't really
discuss those issues much here.".

Just my $2/100. Is it too off topic to discuss the topic of the
newsgroup? I hope not.

It's not too off topic to discuss the topic of the newsgroup.
Topicality is on on topic everywhere always.
This newsgroup is USENET first and about C second.

You would probably get a better answer in comp.std.c,
we don't really discuss those issues much here.

The past and present versions are on topic here.
The many non-standard versions and extensions are not.

The people who will actually be making the changes
to the future version, are on comp.std.c.
They like to discuss ideas regarding future changes to the language.
 
A

Adam Ruth

Irrwahn Grausewitz said:
Because:

- questions about 'pure' standard (ISO) C are topical in comp.lang.c
- questions about the C (ISO) standard are topical in comp.std.c
- questions about C plus non-standard/implementation-dependent
extensions to the language are topical in newsgroups dedicated to
these extensions/implementations. If there is no such group, there is
still comp.programming.

HTH
Regards

Great non-answer, you already pointed this out.

Let's look at the topic of the question:

"Has there been talk of adding named parameters to C?"

1) Not really a question about 'pure' standard (ISO) C.
2) Not really a question about the C (ISO) standard.
3) Not really a question about non-standard/implementation dependent
extensions.

So where does it go? Even if there was a non-standard implementation
of this functionality, how would I know which newsgroup to ask it in,
should it have been posted in all of them? What if that particular
implentation doesn't have a newsgroup?

This may come as a shock to you, but it's actually possible for a
question to apply to more than one newsgroup.

Technically, it's not a question about C so much as it is a question
about a discussion about C. Should that go to comp.lang.discussion.c?
It's possible take pedantry too far.
 
A

Adam Ruth

pete said:
It's not too off topic to discuss the topic of the newsgroup.
Topicality is on on topic everywhere always.
This newsgroup is USENET first and about C second.

You would probably get a better answer in comp.std.c,
we don't really discuss those issues much here.

The past and present versions are on topic here.
The many non-standard versions and extensions are not.

The people who will actually be making the changes
to the future version, are on comp.std.c.
They like to discuss ideas regarding future changes to the language.

Thank you. Had I actually known there was a comp.std.c newsgroup I
would have posted the question there (we can't all be intimately aware
of the usenet structure). I would still have posted the question
here, because my question really is bigger than the standard.

The problem is, that to know the limits of the comp.lang.c newsgroup,
it needs to be taken in context with all of the other newsgroups (it's
not so much an issue of where does comp.lang.c end, but where does
comp.std.c begin). And as I said before, there's nothing in the
comp.lang.c name or in the FAQ that would lead someone to think that
the question was off-topic.
 
M

Mark McIntyre

Why? It wasn't a question about standard C, it was a question about C.

You have the groups confused:

CLC discusses Standard C, ie the language as standardised

CSC discusses the Standard itself ie the actual document, and possible
changes to it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top