Skip Menu |
Report information
Id: 122653
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: masak <cmasak [at] gmail.com>
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [NYI] 'is iffy' for custom infix operators
From: Carl Mäsak <cmasak [...] gmail.com>
To: rakudobug [...] perl.org
Date: Sat, 30 Aug 2014 10:58:08 +0200
Download (untitled) / with headers
text/plain 2.1k
<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 Show quoted text
it> (such as a match object). All the comparison operators are iffy, as 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.
Still NYI (2017.11, HEAD(5929887))

On 2014-08-30 01:58:28, masak wrote:
Show quoted text
> <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.




This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org