Re: Default precedence level of user defined infix ops

[Luke Palmer]

On 5/18/05, Ingo Blechschmidt <ibl...@web.de> 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) {
> set(@set).includes($item);
> }
> "foo" ∈ <bar baz foo>; # true
> 23 ∈ <bar baz foo>; # false
>
> ...we wondered what the default precedence of those user defined infix ops
> should be.

In the absence of a trait specifying otherwise, the precedence
defaults to the same as infix:<+>.

> 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:<+>) {...}

Luke

[Ingo Blechschmidt]

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" ∈ <bar baz foo>; # true
23 ∈ <bar baz foo>; # false

...we wondered what the default precedence of those user defined infix ops
should be.

And how do I explicitly define the precedence?

--Ingo

--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon! |

[Sam Vilain]

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 Haskell's
() circumfix operator, like ((+) 1 2) ≍ (1 + 2).

Which method does &infix:<+> refer to, if you have;

multi sub infix:<+>(Num $i, Num $j) { $i.add($j) }
multi sub infix:<+>(Set $i, Set $j) { $i.union($j) }

?

Are these automatically locked to the same level, in fact, does it
make sense for any 'operator' (ie, the sub's short name) to exist
in multiple precedence levels at once?

Or is it simply a major ParseF*** to have to determine precedence
/after/ determining types of operands?

Sam.

[Damian Conway]

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 precisely where they're changing it.

On the other hand, if we do end up with a default (still a Bad Idea, IMHO), it
probably should be C<< is looser(&infix:<+>) >>, so that people don't have to
rewire their understanding of the standard precedence sets every time someone
who's defining an operator is too lazy to think about precedence or to type
two dozen extra characters.

Damian