Re: Checking for nil return

[Darren Duncan]

On 2020-12-29 6:26 a.m., Ruud H.G. van Tol wrote:

Basically, never mix error-state and return-value.
Rather use a different channel/dimension for each.


Such a separation can't be absolute though.  One needs to be able to user-define 
routines that implement additional generic Failure related features, and in that 
case they WOULD be normal arguments or return values.  And so the regular type 
system still needs to support having anything at all as an argument or return 
value. -- Darren Duncan

Re: Checking for nil return

[yary]

Moving the "can't catch Nil return, why is Nil also a failure?" question to
a Raku issue, https://github.com/Raku/doc/issues/3760

This got me going through Raku source code to see where Nil gets passed
through; this looks promising. rakudo/src/vm/moar/spesh-plugins.nqp line 308

# Allow through Nil/Failure
(nqp::istype($rv, Nil) || (nqp::istype($rv, $type) &&
...

Mostly for my own education, though if the discussion goes along the lines
of "let's make Nil not a failure" then I may look at a patch to make it so.

-y


On Wed, Dec 30, 2020 at 10:02 PM yary  wrote:

> This commit shows where Nil expanded from being "Absence of a value" to,
> alternatively, "a benign failure". Unfortunately I haven't found discussion
> on "benign failure" – semantics, use case, prior art, example, that sort of
> thing – and the commit doesn't elaborate.
>
> https://github.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec
>
> I added a comment to that commit, which is now nearly 5 years old. Would
> be good to get a follow up from the committer!
>
> -y
>
>
> On Tue, Dec 29, 2020 at 9:28 AM Ruud H.G. van Tol 
> wrote:
>
>>
>> Basically, never mix error-state and return-value.
>> Rather use a different channel/dimension for each.
>>
>> And any value itself can have special state too, like "absence" and (via
>> its type) "has-default".
>>
>> On that docs-page, my stomach protested against the Nil/default pairing.
>> Now I need to think through why it (grumbled that it) is wrong.
>> (or not wrong: for performance reasons, it is good to support values
>> that can never be undefined)
>>
>> -- Ruud
>>
>>
>> On 2020-12-28 22:35, yary wrote:
>> > [...]
>> > Allowing Failure as a return always makes sense to me– every block
>> needs
>> > to be capable of passing along a failure, that's how the language is
>> > designed.
>> >
>> > On the other hand, Nil is not a Failure. Conceptually it is a lack of
>> an
>> > answer, similar to SQL's null concept.
>> >
>> > What's the usefulness of having Nil skip return type checking-
>> > specifically Nil and not its Failure descendents?
>> >
>> > This example under https://docs.raku.org/type/Nil
>> >  shows what I think is a
>> > less-than-awesome specification, and I am curious about the reasoning
>> > behind it being defined as valid
>> >
>> > suba( -->Int:D ) { return Nil }
>>
>