Hi -
Ok, thanks for clarifying. I'm on board with this solution to 1 and 2 (adding
also
the symmetric "return value used"). For 3, compile time vs. run time - I'm a
little
bit worried about code size, but am OK with it being compile time.
Cheers,
-michael
On 12/11/2013 11:45 AM, Brad Chamberlain wrote:
>
> 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
