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:
> 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) {
>
