fox@cs.cs.columbia.edu (David Fox) (07/24/89)
It seems to me that as long as you are going to have default argument values, you might as well allow any combination of arguments to be omitted. I often find myself trying to figure out what order to put the arguments of a function in so that I can give the "right ones" default values. I often fail to find that order: many functions just aren't that "linear". The way to do this is to allow caller to name the parameters the way Ada does: foo(parm1 = a, parm3 = b, parm2 = c). Is it too late to add this, or something like it, to C++? G++? Would it be a Good Thing? Would it break anything? Has it already been discussed? Can I have it by Tuesday? David Fox fox@cs.columbia.edu P.S. If it can't be part of the language, perhaps this could be done with a preprocessor?
beshers@cs.cs.columbia.edu (Clifford Beshers) (07/24/89)
In article <FOX.89Jul23151217@cs.cs.columbia.edu> fox@cs.cs.columbia.edu (David Fox) writes:
It seems to me that as long as you are going to have default
argument values, you might as well allow any combination of
arguments to be omitted. I often find myself trying to
figure out what order to put the arguments of a function in
so that I can give the "right ones" default values. I often
fail to find that order: many functions just aren't that
"linear".
I have fought this problem as well.
The way to do this is to allow caller to name the parameters
the way Ada does: foo(parm1 = a, parm3 = b, parm2 = c).
Is it too late to add this, or something like it, to C++? G++?
The problem is that it is already there, but with different semantics:
void foo(int parm1, int parm3, int parm2)
{ ... }
...
int parm1, parm2, parm3;
foo(parm1 = 1, parm2 = 3, parm3 = 2);
What interpretation do you place on this?
--
-----------------------------------------------
Cliff Beshers
Columbia University Computer Science Department
beshers@cs.columbia.edudlw@odi.com (Dan Weinreb) (07/24/89)
In article <FOX.89Jul23151217@cs.cs.columbia.edu> fox@cs.cs.columbia.edu (David Fox) writes:
The way to do this is to allow caller to name the parameters
We did exactly this to Common Lisp, for exactly the reason you cite.
(Actually we did it to Common Lisp's ancestor, the MIT Lisp Machine
dialect of Lisp, and the feature was carried over into Common Lisp).
It turned out to be useful and is used fairly often in large Lisp
programs. In my opinion, in the abstract, it would be a good thing.
I can certainly see why making such a change to C++ at this point in
its life might be significantly more difficult than making such a
change to Lisp was in the late 1970's. But in this I should defer to
the C++ designers, since I don't know all the considerations and
ramifications.
Dan Weinreb Object Design, Inc.lpringle@bbn.com (Lewis G. Pringle) (07/25/89)
In article <FOX.89Jul23151217@cs.cs.columbia.edu> fox@cs.cs.columbia.edu (David Fox) writes: >The way to do this is to allow caller to name the parameters >the way Ada does: foo(parm1 = a, parm3 = b, parm2 = c). I second the emotion, but it may be harder than it looks. What your are describing (I think) are called keyword parameters. The difficulty, is that they impose even more ambiguity into the language. Default params, together with overloading, and conversion operators, already add lots ambiguity - keyword paramers would make things even worse. The ambiguity can - of cousrse be resolved by disambiguating rules. Any ADA people want to share their experiences. Lewis. "OS/2: half an operating system for half a computer." In Real Life: Lewis Gordon Pringle Jr. Electronic Mail: lpringle@labs-n.bbn.com Phone: (617) 873-4433
schmidt@glacier.ics.uci.edu (Doug Schmidt) (07/26/89)
In article <43253@bbn.COM>, lpringle@bbn (Lewis G. Pringle) writes: >In article <FOX.89Jul23151217@cs.cs.columbia.edu> fox@cs.cs.columbia.edu (David Fox) writes: >>The way to do this is to allow caller to name the parameters >>the way Ada does: foo(parm1 = a, parm3 = b, parm2 = c). > >I second the emotion, but it may be harder than it looks. What your are >describing (I think) are called keyword parameters. The difficulty, >is that they impose even more ambiguity into the language. Default params, >together with overloading, and conversion operators, already add >lots ambiguity - keyword paramers would make things even worse. There's also another problem. Allowing ``named parameters,'' a la Ada, weakens information hiding, since formal parameter names are now visible *outside* their original scope! For example, consider the effect of changing a formal parameter name in C or C++. All you need to modify are the uses of this formal parameter name *inside* the enclosing function. This change is trivial to perform using an interactive query-replace editor feature. On the other hand, in a language that allows named parameters you need to hunt down all instances of the formal parameter names occurring in all *calls* to the function. These calls are potentially spread throughout many source files, and it becomes difficult to change the names in an automated fashion, for the reasons alluded to above. IMHO, named parameters are another Ada (mis)feature that adds gratuitous complexity to the compiler and programmer without providing much value-added benefit. Doug -- Master Swordsman speak of humility; | schmidt@ics.uci.edu (ARPA) Philosophers speak of truth; | office: (714) 856-4034 Saints and wisemen speak of the Tao of no doubt; The moon, sun, and sea speaks for itself. -- Hiroshi Hamada