Hi Brad,
(3) is a very good point. While I don't see (1) and (2) as a major
objection, they do point out that for "undefined" to be useful in the
common case, an undefined variable should be assignable. This essentially
means that a variable may have two values (it's actual value and
"undefined") which is absurd so I'll concede.
As it stands, if you want to be able to omit an argument to a function then
it needs to be given a default value. This does not help much with my
motivating example (error propagation) because the error state must be
passed by reference, and so the default variable must be an lvalue. You
could do this:
var _foo_err: errorstate;
proc foo(ref err = _foo_err) {
// ...
}
But this is clunky and not thread safe.
How about allowing something like this:
proc foo(ref err?: errorstate) { ... }
which would be semantically equivalent to:
proc foo(ref err: errorstate) { ... }
proc foo() { var err: errorstate; foo(err); }
Note that the type is necessary: If you only declared "proc foo(ref err?)"
then the compiler would not know what the type of err is in the call
"foo()". Perhaps this is not actually a problem: in this case, the
compiler could instead just mark the variable as "I don't know what the
type of this is" (much like my original "undefined" suggestion) and only
raise an error if you try to actually do something with the variable other
than use its defaultValueUsed method.
Chris
On 6 December 2013 04:27, Brad Chamberlain <[email protected]> wrote:
> 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
