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
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
ays 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.
> >
> &g
e 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 descend
able 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
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
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 {
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" pa
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
>
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.
10 matches
Mail list logo