Aaron Sherman wrote:
See below for the S06 section I'm referring to.
I'm wondering how we should be reading the description of user-defined
operators. For example, "sub infix:<(c)>" doesn't describe
the precedence level of this new op, so how is it parsed? Is there a
default?
The default is same as infix:<+> for infix ops, however the is prec
trait (and some other related ones) should also be available (but not
yet implemented in Rakudo).
Right now, this doesn't work as I'd expect in Rakudo for all categories. For
example:
$ ./perl6 -e 'sub infix:<i> ($a,$b) { return $a+($b*1i); } ; say 3 i 2'
3 + 2i
Correct.
$ ./perl6 -e 'sub term:<i> () { return 1i; } ; say i'
error:imcc:syntax error, unexpected '\n'
in file 'EVAL_1' line 105914178
Eh? What newline? And line 105914178?
Yeah, our handling of categories we don't handle yet is crappy; it ends
up boiling down to a code generation fail.
OK, so that's a bug, but the question is, should I expect it to work?
Yes, I believe it should.
<skipping macros bit for somebody else who groks them> :-)
I think there's also a bug in the examples when it comes to ±. That can be a
method, sure, that makes sense, but in which case I don't think it should be
taking a parameter. Wouldn't that be:
method prefix:<±> (--> Num) { return +self.myintvalue | -self.myintvalue
}
So that it would be used like so:
my $x = MyInt.new(:myintvalue(5));
say ±$x;
which I would expect to yield:
any(5, -5)
The method case makes no sense to me. It almost certainly won't be any
use unless the method gets exported, since operator dispatches are
always sub dispatch. Maybe that example is a fossil that should go away.
And if not, then yes, it most certainly would want to be written in
terms of self, not have a parameter. So something is wonky with the spec
here.
Hope this helps a little,
Jonathan
