Still NYI (2017.11, HEAD(5929887))
On 2014-08-30 01:58:28, masak wrote:
> <masak> how do I make a custom op iffy?
> <TimToady> well, equiv should dup iffy-ness, I'd think, along with all
> the other attributes of an operator
> <TimToady> tighter and looser are of course more problematic
> <masak> should there maybe be an 'is iffy' trait?
> <jnthn> That'd make sense to me...
> <TimToady> or it could be intuited from the return type, possibly
> <TimToady> presumably something that returns Bool is naturally iffy
> <masak> all those things sound like frills on top of the mundane,
> reliable mechanism...
> <TimToady> yeah
> * masak submits 'is iffy' NYI ticket
>
> Here's something that works already:
>
> $ perl6 -e 'sub infix:<≃>($l, $r) { $l == $r }; say 4 ≃ 5'
> False
>
> The following doesn't. The above clog should be read as a discussion
> around that:
>
> $ perl6 -e 'sub infix:<≃>($l, $r) { $l == $r }; say 4 !≃ 5'
> ===SORRY!=== Error while compiling -e
> Cannot negate ≃ because it is not iffy enough
> [...]
>
> My suggestion is to simply use 'is iffy' for this which today doesn't
> work simply because it's Not Yet Implemented. As far as I can see,
> this code oughta work when it is:
>
> $ perl6 -e 'sub infix:<≃>($l, $r) is iffy { $l == $r }; say 4 !≃ 5'
> ===SORRY!=== Error while compiling -e
> Can't use unknown trait 'is iffy' in a sub+{precedence} declaration.
> [...]
>
> TimToady has two other suggestions which also make sense to me, but
> only in special cases.
>
> S03 doesn't mention 'iffy' at all. S99 does:
>
> ----
>
> =head2 iffy
>
> Used of an operator that either returns a C<Bool> result, I<or
> something like
> it> (such as a match object). All the comparison operators are iffy, as
> it> are
> conditional operators like C<&&>, C<?^>, and C<or>. C<%%> is iffy, but
> C<%>
> isn't. The junctive operators are iffy.
>
> The reason that we care about iffy operators is that you can only
> append the
> C<!> metaoperator to an operator that's iffy.
>
> ----
>
> The term originated in STD.pm6, and up until this ticket I'm aware of
> no effort or discussion to make it user-facing. I'm not tied to any
> one particular mechanism for exposing iffiness to userland, but I
> firmly believe that it should be exposed; otherwise built-in operators
> will have an advantage over user-defined ones, which feels un-Perlish.
