Re: Checking for nil return

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

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" =E2=80=93 semantics, use case, prior art, example, that=
 sort of
thing =E2=80=93 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 <[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 bl=
ock 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 a=
n
> > 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 }
>

--00000000000043fbb105b7b9dca7
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"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">This commit shows where Nil exp=
anded from being &quot;Absence of a value&quot; to, alternatively, &quot;a =
benign failure&quot;. Unfortunately I haven&#39;t found discussion on &quot=
;benign failure&quot; =E2=80=93 semantics, use case, prior art, example, th=
at sort of thing =E2=80=93 and the commit doesn&#39;t elaborate. </div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/Raku/=
doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec">https://github.com/Rak=
u/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec</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" class=3D"gmail_signature">-y<br></div></div><br>=
</div></div></div></div></div></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 29, 2020 at 9:28 AM Ruud H.=
G. van Tol &lt;<a href=3D"mailto:[email protected]">[email protected]</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-col=
or: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 &quot;absence&quot; a=
nd (via <br>
its type) &quot;has-default&quot;.<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>
&gt; [...]<br>
&gt; Allowing Failure as a return always makes sense to me=E2=80=93 every b=
lock needs <br>
&gt; to be capable of passing along a failure, that&#39;s how the language =
is <br>
&gt; designed.<br>
&gt; <br>
&gt; On the other hand, Nil is not a Failure. Conceptually it is a lack of =
an <br>
&gt; answer, similar to SQL&#39;s null concept.<br>
&gt; <br>
&gt; What&#39;s the usefulness of having Nil skip return type checking- <br=
>
&gt; specifically Nil and not its Failure descendents?<br>
&gt; <br>
&gt; 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>
&gt; &lt;<a href=3D"https://docs.raku.org/type/Nil" rel=3D"noreferrer" targ=
et=3D"_blank">https://docs.raku.org/type/Nil</a>&gt; shows what I think is =
a <br>
&gt; less-than-awesome specification, and I am curious about the reasoning =
<br>
&gt; behind it being defined as valid<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0suba( --&gt;Int:D=C2=A0) { return Nil }<br>
</blockquote></div>

--00000000000043fbb105b7b9dca7--