Re: Checking for nil return

2020-12-31 Thread Darren Duncan
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

Re: Checking for nil return

2020-12-31 Thread yary
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

Re: Checking for nil return

2020-12-30 Thread yary
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

Re: Checking for nil return

2020-12-29 Thread Ruud H.G. van Tol
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

Re: Checking for nil return

2020-12-28 Thread Brad Gilbert
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

Re: Checking for nil return

2020-12-28 Thread yary
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

Re: Checking for nil return

2020-12-20 Thread Brad Gilbert
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 {

Re: Checking for nil return

2020-12-20 Thread yary
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

Re: Checking for nil return

2020-12-20 Thread Joseph Brenner
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 >

Checking for nil return

2020-12-19 Thread yary
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.