Luke Palmer wrote:
> In the absence of a trait specifying otherwise, the precedence
> defaults to the same as infix:<+>.
Heh. It'd be much safer to *require* a precedence specification on any new
operator. If they're changing the parser, they ought to have the decency to be
explicit about precise
Luke Palmer wrote:
And how do I explicitly define the precedence?
Using the `tighter`, `looser`, and `equiv` traits. You specify
precedence in terms of the precedence of other existing ops.
sub infix:<.>(&f, &g) is looser(&infix:<+>) {...}
This is interesting. So, infix:< > is similar to Hask
On 5/18/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
(B> Hi,
(B>
(B> now that the following works in Pugs :)...
(B>
(B> sub infix:<.> (Code &x, Code &y) { sub ($z) { x(y($z)) } }
(B> (&say . &int)(10/3);# 3
(B>
(B> use Set;
(B> sub infix:<$B":(B> ($item, @set) {
(B>
Hi,
now that the following works in Pugs :)...
sub infix:<.> (Code &x, Code &y) { sub ($z) { x(y($z)) } }
(&say . &int)(10/3);# 3
use Set;
sub infix:<â> ($item, @set) {
set(@set).includes($item);
}
"foo" â ; # true
23â ; # false
...we wondered what the
