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 fe
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
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/com
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 thin
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
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
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 { ret
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 che
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
>> out-check(44)
> 44
>> out-check(Nil)
> Nil
>
> ^ Huh, I expected an exception on "out-check(Nil)" saying the return
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
> out-check(44)
44
> out-check(Nil)
Nil
^ Huh, I expected an exception on "out-check(Nil)" saying the return value
failed the "returns" cons
10 matches
Mail list logo
