Hi -
One more thing... In a sidebar discussion with Brandon, he suggested that
I/O routines could return a 'status' which would count as 'true' if
the operation was successful, and otherwise encode an error code. I like
the idea of putting that information in the return code, since
it reduces the amount of noise when a programmer wants to handle the
error cases. But the problem is - what if the programmer does not consume
the error code?
I predict that any Chapel programmer doing rapid prototyping will want
to ignore the error codes. The reasonable default behavior - if the
error code is not checked - is to halt the program as soon as the error
is detected. (raising an exception is another way of expressing that
default behavior that allows other procedures, modules, or tasks to handle
the error. I will assume that in the future, 'halt' will raise some
kind of exception). So maybe all we need is a way to know if the return value
was consumed.
So, Solution D would look something like:
proc foo():int {
var err = ...;
if returnValueIgnored && err != 0 then halt(err);
return err;
}
var err = foo(); // returnValueIgnored = false
foo(); // returnValueIgnored = true
and, more concretely, for writeln, we'd have something like:
proc writeln():status { ... }
writeln(); // halts if there was an I/O error
if writeln() then ... // does not halt if there was an I/O error
var status = writeln(); // does not halt if there was an I/O error
Thoughts?
-michael
On 12/11/2013 10:35 AM, 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
>
------------------------------------------------------------------------------
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
