I think what we agreed upon ("we" being me and Chris primarily, though in
side conversations others have aquiesced as well) was an option D:
1) The presence of a default value for an argument marks it as optional
(this is what we already have today);
2) Some sort of built-in .defaultValueUsed method or procedure would be
used to determine whether the optional value was specified. A function
would be almost trivial to implement but would clutter the namespace; a
method would be slightly harder to implement, but not too much
presumably. I'm not tied to this specific name at all.
3) I view this as a compile-time (param) procedure since it's knowledge
that's known at compile-time and could be useful for folding away
unused code paths.
I think the main possible objection to this approach is that we've
essentially said that for a case like:
proc foo(ref x: int = 1000) { ... }
there's some sleight of hand going on in that '1000' is not a legal lvalue
so technically shouldn't be able to be "passed" to x by reference. One
interpretation here (as with 'inout' and 'out' intents currently) is that
a temporary variable would be inserted to hold the default value and that
is what would be "passed" by reference into the procedure. An alternate
interpretation would be that since the 1000 is only used when an 'x' was
not supplied at the callsite, the 'ref' semantics are somewhat moot.
I.e., we may as well simply consider 'x' to have intent 'in' in this case
(since there's nothing to refer back to) in which case 'x' is itself the
temporary variable and it gets the value 1000 (this may also provide an
optimization/specialization opportunity at compile-time since 'x' can be
referred to more cheaply when the callsite doesn't supply one).
While this feels, arguably, a little fiddly/sloppy, I think the consensus
(again, of a small sample size) is that the utility, convenience, and lack
of alternate reasonable interpretation for such a case makes it acceptable
(combined with the corresponding syntactic baggage we expect for any other
solution -- or maybe just the lack of one that feels sufficiently
compelling and attractive?).
-Brad
On Wed, 11 Dec 2013, Michael Ferguson wrote:
> 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
