Re: Checking for nil return

--00000000000058eca205b78d1ffc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The closest to null is actually an undefined type object

On Mon, Dec 28, 2020, 3:36 PM yary <[email protected]> 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=E2=80=93 every bloc=
k 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>> Is this a known issue, or my misunderstanding?
>>>
>>> > subset non-Nil where * !=3D=3D=3D Nil;
>>> (non-Nil)
>>> > sub out-check($out) returns non-Nil { return $out }
>>> &out-check
>>> > 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
>>> > 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 <unknown file> line 1
>>>   in block <unit> at <unknown file> 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
>>>
>>

--00000000000058eca205b78d1ffc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">The closest to null is actually an undefined type object<=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Mon, Dec 28, 2020, 3:36 PM yary &lt;<a href=3D"mailto:[email protected]">=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Been thinking about this, =
and checked out the Rakudo repository to peek into the source.<div><br></di=
v><div>Allowing Failure as a return always makes sense to me=E2=80=93 every=
 block needs to be capable of passing along a failure, that&#39;s how the l=
anguage is designed.</div><div><br></div><div>On the other hand, Nil is not=
 a Failure. Conceptually it is a lack of an answer, similar to SQL&#39;s nu=
ll concept.</div><div><br></div><div>What&#39;s the usefulness of having Ni=
l skip return type checking- specifically Nil and not its Failure descenden=
ts?</div><div><br></div><div>This example under <a href=3D"https://docs.rak=
u.org/type/Nil" target=3D"_blank" rel=3D"noreferrer">https://docs.raku.org/=
type/Nil</a> shows what I think is a less-than-awesome specification, and I=
 am curious about the reasoning behind it being defined as valid</div><div>=
<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><span style=3D"color:rgb(166,38,164);font-w=
eight:bold;font-family:monospace;font-size:14px;white-space:pre-wrap">sub</=
span><span style=3D"color:rgb(0,0,0);font-family:monospace;font-size:14px;w=
hite-space:pre-wrap">=C2=A0</span><span style=3D"color:rgb(153,0,0);font-fa=
mily:monospace;font-size:14px;white-space:pre-wrap">a</span><span style=3D"=
color:rgb(0,0,0);font-family:monospace;font-size:14px;white-space:pre-wrap"=
>(=C2=A0</span><span style=3D"font-weight:bold;font-family:monospace;font-s=
ize:14px;white-space:pre-wrap">--&gt;</span><span style=3D"color:rgb(0,0,0)=
;font-family:monospace;font-size:14px;white-space:pre-wrap">=C2=A0</span><s=
pan style=3D"color:rgb(68,85,136);font-family:monospace;font-size:14px;whit=
e-space:pre-wrap">Int</span><span style=3D"color:rgb(0,0,0);font-family:mon=
ospace;font-size:14px;white-space:pre-wrap"><span style=3D"color:rgb(34,34,=
34);font-weight:bold">:</span><span style=3D"color:rgb(0,86,195);font-weigh=
t:bold">D</span></span><span style=3D"color:rgb(0,0,0);font-family:monospac=
e;font-size:14px;white-space:pre-wrap">=C2=A0)=C2=A0</span><span style=3D"c=
olor:rgb(0,0,0);font-family:monospace;font-size:14px;white-space:pre-wrap">=
<span>{</span>=C2=A0<span style=3D"color:rgb(34,34,34);font-weight:bold">re=
turn</span>=C2=A0<span style=3D"color:rgb(68,85,136)">Nil</span>=C2=A0<span=
>}</span></span></blockquote><div><br></div><div><br></div><div><div dir=3D=
"ltr">-y<br></div></div><br></div></div></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Dec 20, 2020 at 7:18 =
PM Brad Gilbert &lt;<a href=3D"mailto:[email protected]" target=3D"_blank" =
rel=3D"noreferrer">[email protected]</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"auto">Nil is always a valid return value regardless of any c=
heck.<div dir=3D"auto"><br></div><div dir=3D"auto">This is because it is th=
e base of all failures.</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, Dec 19, 2020, 8:17 PM yary &lt;<a hre=
f=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer">not.com=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width: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"ltr"><div dir=3D"ltr"><div dir=3D"=
ltr"><div dir=3D"ltr">Is this a known issue, or my misunderstanding?</div><=
div dir=3D"ltr"><br></div><div dir=3D"ltr">&gt; subset non-Nil where * !=3D=
=3D=3D Nil;<br></div><div dir=3D"ltr">(non-Nil)</div><div dir=3D"ltr"><div =
dir=3D"ltr"><div dir=3D"ltr">&gt; sub out-check($out) returns non-Nil { ret=
urn $out }</div><div dir=3D"ltr">&amp;out-check</div><div dir=3D"ltr">&gt; =
out-check(44)</div><div dir=3D"ltr">44</div><div dir=3D"ltr">&gt; out-check=
(Nil)</div><div dir=3D"ltr">Nil</div><br>^ Huh, I expected an exception on =
&quot;out-check(Nil)&quot; saying the return value failed the &quot;returns=
&quot; constraint.</div><div dir=3D"ltr"><br></div><div>The subtype works a=
s I expect as an the argument check</div><div dir=3D"ltr"><br></div><div di=
r=3D"ltr">&gt; sub in-check (non-Nil $in) { $in }</div><div dir=3D"ltr">&am=
p;in-check</div><div dir=3D"ltr">&gt; in-check(33)</div><div dir=3D"ltr">33=
</div><div dir=3D"ltr">&gt; in-check(Nil)</div><div dir=3D"ltr">Constraint =
type check failed in binding to parameter &#39;$in&#39;; expected non-Nil b=
ut got Nil (Nil)</div><div dir=3D"ltr">=C2=A0 in sub in-check at &lt;unknow=
n file&gt; line 1</div><div dir=3D"ltr">=C2=A0 in block &lt;unit&gt; at &lt=
;unknown file&gt; line 1</div><div><br></div></div><div dir=3D"ltr"><div di=
r=3D"ltr">$ raku --version</div><div dir=3D"ltr">This is Rakudo version 202=
0.07 built on MoarVM version 2020.07</div><div dir=3D"ltr">implementing Rak=
u 6.d.</div></div><div dir=3D"ltr"><br></div><div>Is this my understanding=
=C2=A0of return type checking that&#39;s off, or a known issue, or somethin=
g I should add to an issue tracker?</div><div><br></div><div dir=3D"ltr"><d=
iv><div dir=3D"ltr">-y<br></div></div></div></div></div></div></div></div><=
/div>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--00000000000058eca205b78d1ffc--