Hi -
Summarizing, and then questions.
- Chris proposed adding an 'undefined' value to check to see if an
optional argument was provided
- Brad proposed allowing something like x.defaultValueUsed
- Chris proposed using e.g. ref err?: errorstate to mark
optional arguments.
- Brad suggested an example of proc foo(ref err = new errorstate());
At that point, I stopped understanding the discussion...
Is there some consensus about the design of this feature? In my mind,
there need to be three decisions:
1) How does a procedure mark an optional argument?
2) How does the procedure check if the optional argument was specified?
3) Is whether or not the argument was specified a compile-time
or run-time variable inside the procedure?
Solution A: ? marks parameters, .defaultValueUsed checks.
Variants on this solution include introducing another argument intent
'optional' or 'optout' or ... and any other choice of name for
.defaultValueUsed :
proc foo(out err?: int = 0) {
err = ...
if err && err.defaultValueUsed then halt(err);
}
var err:int;
foo(err);
Solution B: do everything with a class
class MyClass {
var isDefault:bool;
var error:int;
}
proc foo(out error = new MyClass(true, 0)) {
var defaultValueUsed = error.isDefault;
err = ...
if err && defaultValueUsed then halt(err);
if !defaultValueUsed then error.errcode = err;
}
var getError = new MyClass(false, 0);
foo(getError);
... use getError.error ...
(I don't like this solution because it adds noise to
the function call site if somebody wanted the error
code, and it adds unnecessary allocator activity).
Solution C: add a 'some' type (or 'optional'),
and then hope for automatic coercion:
// in a library somewhere
record some {
var empty:bool = true;
var value:ref;
proc hasValue { return !empty; }
}
proc foo(out error = new some(int)) {
err = ...
if err && error.empty then halt(err);
}
var err:int;
foo(err); // hopefully the int argument will promote to some(int)
// but you would write foo(new some(err) if not.
A problem with this solution is that the value in some has to be
a reference to the original err argument, which seems to be asking
more of the language than the other options. However, if the
'some' type were defined in the language rather than in a library,
at least it would still be clear how to handle (2).
I like A and C could be made to work (but it would probably
look more like a different way of writing A). I don't view B
as a solution, so I'm hoping that's not what you just agreed upon...
Cheers,
-michael
On 12/09/2013 08:36 PM, Brad Chamberlain wrote:
>
> Oh, good! Now we just need someone to implement the behavior for ref
> intents and document the old and new behavior... :) I'm hoping that the
> implementation will be a fairly simple matter of finding and duplicating
> the logic that's used for 'inout' intents.
>
> -Brad
>
>
> On Mon, 9 Dec 2013, Chris Doris wrote:
>
>> Aha! I was not aware that there was this special case for out and inout
>> intents --- it's not in the spec. If I was, I would merely have suggested
>> extending it to the ref intent. I agree that syntax shouldn't be added
>> without good reason, it was just the easiest way to explain the feature.
>>
>> This discussion has deepened my understanding of Chapel. Thank you!
>>
>> 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
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
