On Mon, Dec 11, 2017 at 3:01 PM, <zof...@zoffix.com> wrote:
>
> On 2017-12-11 12:22 PM, Sean McAfee wrote:
>
>> Well, not really. I don't think x %% 0 should return a Failure at all.
>>
>
> Is there a particular problem the current implementation fails to solve?
> In boolean
> context `x %% 0` *is* equivalent to False. The Failure carries additional
> information
> to those who want it. You can discard that information with `so x %% 0` if
> you aren't
> already evaluating in Bool context. Seems returning a Failure is the best
> of both worlds.
>
>
Well, *any* function or operator that returns a boolean *could* return a
Failure instead of (or in addition to) False to provide additional
information to those who want it, but if the condition is not really a
Failure, wouldn't that be misleading? Like this highly contrived example:
sub is-nonzero($x) { $x.Num / $x.Num }
I feel that %% returning a Failure when given a zero second argument is
similarly misleading/unhelpful. At least, if the intention of "a %% b" is
simply to return whether a is divisible by b. If it's explicitly intended
to mean just "a % b == 0" and inherit all of the failure modes of the %
operator, then fine, I suppose. It seems more clunky to me, though.
1 / 0 is an expression which can evaluate to no sensible value
>
> It can produce a sensible value. In floating point context (that is in Num
> view), that's a perfectly cromulent positive infinity, again per IEEE 754
> standard:
>
> <Zoffix> m: say (1 / 0).Num
> <camelia> rakudo-moar fed56be25: OUTPUT: «Inf»
>
>
To be perfectly cromulent I'd expect to be able to multiply that Inf by 0
and get my 1 back.
