Re: Checking for nil return
[email protected] (yary) Thu, 31 Dec 2020 16:14:22 -0500
| Newsgroups | perl.perl6.language |
|---|---|
| Message-ID | <CAG2CFAYp_0UjWmYiifcVmi3ue5_LFo6nRbkn9fOLHOKJ01bbzg@mail.gmail.com> |
--0000000000003b1fda05b7c91c3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 30=
8
# 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 <[email protected]> wrote:
> This commit shows where Nil expanded from being "Absence of a value" to,
> alternatively, "a benign failure". Unfortunately I haven't found discussi=
on
> on "benign failure" =E2=80=93 semantics, use case, prior art, example, th=
at sort of
> thing =E2=80=93 and the commit doesn't elaborate.
>
> https://github.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513=
ec
>
> 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 <[email protected]>
> 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=E2=80=93 every b=
lock
>> 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
>> > <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 }
>>
>
--0000000000003b1fda05b7c91c3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Moving =
the "can't catch Nil return, why is Nil also a failure?" ques=
tion to a Raku issue, <a href=3D"https://github.com/Raku/doc/issues/3760">h=
ttps://github.com/Raku/doc/issues/3760</a></div><div dir=3D"ltr"><br></div>=
<div>This got me going through Raku source code to see where Nil gets passe=
d through; this looks=C2=A0promising.=C2=A0rakudo/src/vm/moar/spesh-plugins=
.nqp line 308</div><div><br></div><div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Allow through Nil/Failure</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (nq=
p::istype($rv, Nil) || (nqp::istype($rv, $type) &&</div></div><div>=
...</div><div><br></div><div>Mostly for my own education, though if the dis=
cussion goes along the lines of "let's make Nil not a failure"=
; then I may look at a patch to make it so.</div><div dir=3D"ltr"><br clear=
=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature">-y<br></div></div>=
<br></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
class=3D"gmail_attr">On Wed, Dec 30, 2020 at 10:02 PM yary <<a href=3D"=
mailto:[email protected]">[email protected]</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">This commit shows whe=
re Nil expanded from being "Absence of a value" to, alternatively=
, "a benign failure". Unfortunately I haven't found discussio=
n on "benign failure" =E2=80=93 semantics, use case, prior art, e=
xample, that sort of thing =E2=80=93 and the commit doesn't elaborate. =
</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github=
.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec" target=3D"_b=
lank">https://github.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4=
f513ec</a></div><br>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!<div dir=3D=
"ltr"><br></div><div dir=3D"ltr"><div><div dir=3D"ltr">-y<br></div></div><b=
r></div></div></div></div></div></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 29, 2020 at 9:28 AM Ruud =
H.G. van Tol <<a href=3D"mailto:[email protected]" target=3D"_blank">rv=
[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Basically, never mix error-state and return-value.<br>
Rather use a different channel/dimension for each.<br>
<br>
And any value itself can have special state too, like "absence" a=
nd (via <br>
its type) "has-default".<br>
<br>
On that docs-page, my stomach protested against the Nil/default pairing. <b=
r>
Now I need to think through why it (grumbled that it) is wrong.<br>
(or not wrong: for performance reasons, it is good to support values <br>
that can never be undefined)<br>
<br>
-- Ruud<br>
<br>
<br>
On 2020-12-28 22:35, yary wrote:<br>
> [...]<br>
> Allowing Failure as a return always makes sense to me=E2=80=93 every b=
lock needs <br>
> to be capable of passing along a failure, that's how the language =
is <br>
> designed.<br>
> <br>
> On the other hand, Nil is not a Failure. Conceptually it is a lack of =
an <br>
> answer, similar to SQL's null concept.<br>
> <br>
> What's the usefulness of having Nil skip return type checking- <br=
>
> specifically Nil and not its Failure descendents?<br>
> <br>
> This example under <a href=3D"https://docs.raku.org/type/Nil" rel=3D"n=
oreferrer" target=3D"_blank">https://docs.raku.org/type/Nil</a> <br>
> <<a href=3D"https://docs.raku.org/type/Nil" rel=3D"noreferrer" targ=
et=3D"_blank">https://docs.raku.org/type/Nil</a>> shows what I think is =
a <br>
> less-than-awesome specification, and I am curious about the reasoning =
<br>
> behind it being defined as valid<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0suba( -->Int:D=C2=A0) { return Nil }<br>
</blockquote></div>
</blockquote></div>
--0000000000003b1fda05b7c91c3f--