Hi Chris --
There's a longstanding feature idea to reduce this duplication of function
definitions, similar to what you are proposing here, yet also different. It
would also be useful in other cases unrelated to function duplication like
this. We've typically viewed this capability as a query that can made against
an argument to determine whether or not an explicit value was supplied for it.
Imagine for example:
proc foo(x = 1) {
if (x.defaultValueUsed) {
writeln("The user didn't pass in a value for x");
} else {
writeln("The user passed in a value for x: ", x);
}
}
(note that I'm not particularly happy with / wed to the name of the method
above, nor whether it should be a method or a function, so just consider it a
placeholder for some sort of query on 'x' using existing concepts). The things
that make me prefer such a query-based approach over your approach are:
1) It permits me to supply a default value that has semantic meaning even if
the user doesn't supply a value; contrast this with your approach where if I
wanted to both query whether a value was supplied and then provide a default
value I'd have to assign x;
2) It doesn't suggest that there is some additional value outside of a
variable's normal range that it can hold (i.e., if x is an integer, it doesn't
lead to natural questions like "what integer value does 'undefined' correspond
to?");
3) related, if we define the defaultValueUsed method as a compiler-provided
param method, it fits the existing language better; put another way, the
language doesn't currently specify compile-time comparisons between variables
and special/param values (what I interpret 'undefined' as being).
Nothing has ever prevented this from being implemented other than nobody's ever
gotten to it. It's been near the top of peoples' TODO lists on a few
occasions, but never gotten popped off. We'd love to see this come in as a
feature if you want to take it.
-Brad
________________________________
From: Chris Doris [[email protected]]
Sent: Thursday, December 05, 2013 5:48 PM
To: [email protected]
Subject: [Chapel-developers] missing function arguments
Hello all,
In the standard library, there is a common convention to have two versions of a
lot of functions. The first version takes a reference to some error state and
if an error occurs in the function, it sets the state and returns. The second
version does not have this error state argument and just halts when an error is
occurred. In pseudocode:
proc foo (..., ref err) {
// do some stuff
if (an error occurred) {
err = SOMETHING_BAD_HAPPENED;
return 0;
}
// etc
}
proc foo (...) {
var err = new errorthing;
var ret = foo(..., err);
if err.occurred then
halt(err);
return ret;
}
It seems like the language could benefit from a special compile-time constant
called "undefined" say. Any variable can take this special value, and you can
test (at compile time) if a variable has this value. You can't do anything
else with an undefined value. Then the above would become:
proc foo (..., ref err = undefined) {
// do some stuff
if (an error occurred) {
if err == undefined then halt(.....);
else { err = .....; return 0; }
}
// etc ...
}
This provides an alternative (compile-time) way of providing optional arguments
to functions, default values being the original (run-time) way --- in a sense
it is analogous to the special value "nil" for classes. It should be more
widely useful than the motivating example above.
I suppose for completeness that types could also take this value.
Aside, with this mechanism you could simplify error propagation even further
with a function "propagate(err, ...)" which either calls halt() if err is
undefined or else sets err. Then the example becomes:
proc foo(.., ref err = undefined) {
// do some stuff
if (an error occurred) {
propagate(err, "uh oh");
return 0;
}
// etc
}
Chris
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
