On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote:
> Consider this junction which you probably shouldn't make but you know
> will happen in the hands of users:
>
> any( 5, 'flarg' ) == 5
>
> Despite having an element that satisfies the condition, it blows up
> because one of them doesn't:
>
> > any(5, "flarg") == 5
> Cannot convert string to number: base-10 number must begin with
> valid digits or '.' in '⏏flarg' (indicated by ⏏)
> in block <unit> at <unknown file> line 1
>
> But, it should't matter that what happens with any other parts of the
> junction if at least one of them satisfies the condition. You could,
> for instance, evaluate that differently so the new junction looks
> something like this:
>
> any( True, Failure );
>
> But, I don't think it should evaluate to another junction at all. The
> comparison operator should evaluate to a Boolean. That Failure will
> never matter because it's equivalent to False.
FWIW the explosion doesn't involve Junctions: "flarg".Numeric is a Failure, but
then an attempt is made to use that failure to evaluate the `==` op, at which
point that Failure's exception is actually thrown:
$ perl6 -e 'dd WHAT "flarg".Numeric'
Failure
$ perl6 -e 'dd WHAT "flarg" == 42'
Cannot convert string to number: base-10 number must begin with valid
digits or '.' in '⏏flarg' (indicated by ⏏)
in block <unit> at -e line 1
Actually thrown at:
in block <unit> at -e line 1
