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