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 }
>>
>

Re: Checking for nil return

[yary]

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 }
>

Re: Checking for nil return

[Ruud H.G. van Tol]

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 }

Re: Checking for nil return

[Brad Gilbert]

The closest to null is actually an undefined type object

On Mon, Dec 28, 2020, 3:36 PM yary  wrote:

> Been thinking about this, and checked out the Rakudo repository to peek
> into the source.
>
> 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
>
> sub a( --> Int:D ) { return Nil }
>
>
>
> -y
>
>
> On Sun, Dec 20, 2020 at 7:18 PM Brad Gilbert  wrote:
>
>> Nil is always a valid return value regardless of any check.
>>
>> This is because it is the base of all failures.
>>
>> On Sat, Dec 19, 2020, 8:17 PM yary  wrote:
>>
>>> Is this a known issue, or my misunderstanding?
>>>
>>> > subset non-Nil where * !=== Nil;
>>> (non-Nil)
>>> > sub out-check($out) returns non-Nil { return $out }
>>> 
>>> > out-check(44)
>>> 44
>>> > out-check(Nil)
>>> Nil
>>>
>>> ^ Huh, I expected an exception on "out-check(Nil)" saying the return
>>> value failed the "returns" constraint.
>>>
>>> The subtype works as I expect as an the argument check
>>>
>>> > sub in-check (non-Nil $in) { $in }
>>> 
>>> > in-check(33)
>>> 33
>>> > in-check(Nil)
>>> Constraint type check failed in binding to parameter '$in'; expected
>>> non-Nil but got Nil (Nil)
>>>   in sub in-check at  line 1
>>>   in block  at  line 1
>>>
>>> $ raku --version
>>> This is Rakudo version 2020.07 built on MoarVM version 2020.07
>>> implementing Raku 6.d.
>>>
>>> Is this my understanding of return type checking that's off, or a known
>>> issue, or something I should add to an issue tracker?
>>>
>>> -y
>>>
>>

Re: Checking for nil return

[yary]

Been thinking about this, and checked out the Rakudo repository to peek
into the source.

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

sub a( --> Int:D ) { return Nil }



-y


On Sun, Dec 20, 2020 at 7:18 PM Brad Gilbert  wrote:

> Nil is always a valid return value regardless of any check.
>
> This is because it is the base of all failures.
>
> On Sat, Dec 19, 2020, 8:17 PM yary  wrote:
>
>> Is this a known issue, or my misunderstanding?
>>
>> > subset non-Nil where * !=== Nil;
>> (non-Nil)
>> > sub out-check($out) returns non-Nil { return $out }
>> 
>> > out-check(44)
>> 44
>> > out-check(Nil)
>> Nil
>>
>> ^ Huh, I expected an exception on "out-check(Nil)" saying the return
>> value failed the "returns" constraint.
>>
>> The subtype works as I expect as an the argument check
>>
>> > sub in-check (non-Nil $in) { $in }
>> 
>> > in-check(33)
>> 33
>> > in-check(Nil)
>> Constraint type check failed in binding to parameter '$in'; expected
>> non-Nil but got Nil (Nil)
>>   in sub in-check at  line 1
>>   in block  at  line 1
>>
>> $ raku --version
>> This is Rakudo version 2020.07 built on MoarVM version 2020.07
>> implementing Raku 6.d.
>>
>> Is this my understanding of return type checking that's off, or a known
>> issue, or something I should add to an issue tracker?
>>
>> -y
>>
>

Re: Checking for nil return

[Brad Gilbert]

Nil is always a valid return value regardless of any check.

This is because it is the base of all failures.

On Sat, Dec 19, 2020, 8:17 PM yary  wrote:

> Is this a known issue, or my misunderstanding?
>
> > subset non-Nil where * !=== Nil;
> (non-Nil)
> > sub out-check($out) returns non-Nil { return $out }
> 
> > out-check(44)
> 44
> > out-check(Nil)
> Nil
>
> ^ Huh, I expected an exception on "out-check(Nil)" saying the return value
> failed the "returns" constraint.
>
> The subtype works as I expect as an the argument check
>
> > sub in-check (non-Nil $in) { $in }
> 
> > in-check(33)
> 33
> > in-check(Nil)
> Constraint type check failed in binding to parameter '$in'; expected
> non-Nil but got Nil (Nil)
>   in sub in-check at  line 1
>   in block  at  line 1
>
> $ raku --version
> This is Rakudo version 2020.07 built on MoarVM version 2020.07
> implementing Raku 6.d.
>
> Is this my understanding of return type checking that's off, or a known
> issue, or something I should add to an issue tracker?
>
> -y
>

Re: Checking for nil return

[yary]

After writing that email, I remembered a bit of logic from a class long
ago, that any assertion made on the empty set is true. Since Nil is a
representation of no results, it would make sense to have assertions about
it return true. I think this example shows an optimization to skip return
type checking on Nil, more than a container reverting to its default value.

In particular the error message on using Nil for "in-check (non-Nil $in)"
says "expected non-Nil but got Nil (Nil)" which is preserving the Nil, it
isn't complaining about Any. And in fact "Any" passes the in-check, as I
expect it to.

I suspect that the return value assertion in the signature is a
work-in-progress– in fact part of the reason this test uses "subset
non-Nil" is that having a "where" clause in the returns signature is
explicitly a TODO:

> sub returns-prime (Int $ident --> Int where *.is-prime) { $ident }
===SORRY!=== Error while compiling:
Cannot do non-typename cases of type_constraint yet

Thus I think that handling "Nil" in the return type checking is similarly
something that is going to be fixed. Though I am still not completely sure
due to the nature of Nil being a defined type object.

-y


On Sun, Dec 20, 2020 at 2:35 PM Joseph Brenner  wrote:

> yary  wrote:
> > Is this a known issue, or my misunderstanding?
> >
> >> subset non-Nil where * !=== Nil;
> > (non-Nil)
> >> sub out-check($out) returns non-Nil { return $out }
> > 
> >> out-check(44)
> > 44
> >> out-check(Nil)
> > Nil
> >
> > ^ Huh, I expected an exception on "out-check(Nil)" saying the return
> value
> > failed the "returns" constraint.
>
> I'm seeing the same behavior that Yary does, and it does seem pretty
> peculiar.
>
> I would guess it has to do with this behavior:
>
> # https://docs.raku.org/type/Nil#index-entry-Nil_assignment
>
> # When assigned to a container, the Nil value (but not any subclass
> # of Nil) will attempt to revert the container to its default
> # value; if no such default is declared, Raku assumes Any.
>
> Something like: the Nil is getting transformed into an empty (Any),
> which passes the constraint, but then gets turned back into a Nil
> later.
>

Re: Checking for nil return

[Joseph Brenner]

yary  wrote:
> Is this a known issue, or my misunderstanding?
>
>> subset non-Nil where * !=== Nil;
> (non-Nil)
>> sub out-check($out) returns non-Nil { return $out }
> 
>> out-check(44)
> 44
>> out-check(Nil)
> Nil
>
> ^ Huh, I expected an exception on "out-check(Nil)" saying the return value
> failed the "returns" constraint.

I'm seeing the same behavior that Yary does, and it does seem pretty peculiar.

I would guess it has to do with this behavior:

# https://docs.raku.org/type/Nil#index-entry-Nil_assignment

# When assigned to a container, the Nil value (but not any subclass
# of Nil) will attempt to revert the container to its default
# value; if no such default is declared, Raku assumes Any.

Something like: the Nil is getting transformed into an empty (Any),
which passes the constraint, but then gets turned back into a Nil
later.