Re: [perl #65878] Rakudo shouldn't allow metaops with the same modifier twice in a row
On Thu, May 21, 2009 at 07:20:57PM +0200, Gianni Ceccarelli wrote:
: On 2009-05-21 Larry Wall la...@wall.org wrote:
: : dakkar rakudo: sub infix:R($a,$b) { $a ~ '-' ~ $b }; sub
: : infix:RR($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y';
: : p6eval rakudo e6b463: OUTPUT«x-yx_y»
: : dakkar now, apart from don't do that, what should happen?
: : [snip]
: : dakkar jnthn: about the meta-operator collision thing, S03 says
: : that you can't modify with '!' forms that start with '!', and you
: : can't modify with '=' forms that end with '='
:
: Ok, let me try to explain what I was aiming at…
:
: If we have a normal operator, whose spelling is the same as a
: meta-modified version of another operator, which one should get
: called? The normal (like rakudo does today), or the meta-modified? IN
: my example, is the output correct, or should it have been «x-yy-x» ?
The output is correct, though perhaps for the wrong reason.
: I don't see a bug here. First, there's no prohibition on multiple
: similar metas anymore. But with regard to the example above, metas
: are parsed as their own tokens, and the infix:RR is longer than
: the meta R, so should take precedence under LTM.
:
: Ok, so this means that rakudo does the right thing, which looks pretty
: sensible to me.
I think rakudo is relying on ordered rules rather than longest token
matching here.
: So normal operators will always take precedence against meta-modified
: operators.
No, the longest token takes precedence, regardless of whether it's
normal or a metaop. But most metops are short, like « or X. The
following infix doesn't count as part of the token. RR takes
precedence over R above by virtue of being a single token.
: Should there be a way to explicitly say I mean a
: meta-operator here? If I write:
:
: sub infix:»ö«($a,$b) { return butterfly between $a and $b }
: sub infix:ö($a,$b) { return abs($a-$b) }
:
: how do I make:
:
: say (1,2,3) »ö« (3,4,5)
:
: print:
:
: 2 2 2
You may always put the actual infix into square brackets to
disambiguate, so:
say (1,2,3) »[ö]« (3,4,5)
(I don't know if rakudo supports that yet though.)
Likewise, you can distinguish R[R] from RR.
Larry
[perl #65878] Rakudo shouldn't allow metaops with the same modifier twice in a row
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #65878]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=65878
dakkar rakudo: sub infix:R($a,$b) { $a ~ '-' ~ $b }; sub
infix:RR($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y';
p6eval rakudo e6b463: OUTPUT«x-yx_y»
dakkar now, apart from don't do that, what should happen?
masak dakkar: don't do that only applies after you've found out
that what happens is really not what you want. :)
dakkar masak: fair enough. the general question is: what should P6
do when meta-generated operators clash with user-defined subs? I
*think* rakudo is doing a sensible thing, btw
masak dakkar: me too.
jnthn dakkar: Your definition just happens later and wins atm, but
it's a little more ty accident than it perhaps should be.
masak depends on whether the auto-defined RR is considered a real
sub. then it should perhaps complain.
jnthn Well, it's a real sub. Question is if we make it a multi...
jnthn But in that case we woulda got a failure here.
jnthn I'm not sure. The spec may have answers.
jnthn But I don't remember seeing any.
dakkar jnthn: about the meta-operator collision thing, S03 says that
you can't modify with '!' forms that start with '!', and you can't
modify with '=' forms that end with '='
jnthn dakkar: Ah, OK, so should probably be an error or some thing for those.
* masak submits rakuodbug
Re: [perl #65878] Rakudo shouldn't allow metaops with the same modifier twice in a row
On Thu, May 21, 2009 at 02:56:23AM -0700, Carl Mäsak wrote:
: # New Ticket Created by Carl Mäsak
: # Please include the string: [perl #65878]
: # in the subject line of all future correspondence about this issue.
: # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=65878
:
:
: dakkar rakudo: sub infix:R($a,$b) { $a ~ '-' ~ $b }; sub
: infix:RR($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y';
: p6eval rakudo e6b463: OUTPUT«x-yx_y»
: dakkar now, apart from don't do that, what should happen?
: masak dakkar: don't do that only applies after you've found out
: that what happens is really not what you want. :)
: dakkar masak: fair enough. the general question is: what should P6
: do when meta-generated operators clash with user-defined subs? I
: *think* rakudo is doing a sensible thing, btw
: masak dakkar: me too.
: jnthn dakkar: Your definition just happens later and wins atm, but
: it's a little more ty accident than it perhaps should be.
: masak depends on whether the auto-defined RR is considered a real
: sub. then it should perhaps complain.
: jnthn Well, it's a real sub. Question is if we make it a multi...
: jnthn But in that case we woulda got a failure here.
: jnthn I'm not sure. The spec may have answers.
: jnthn But I don't remember seeing any.
: dakkar jnthn: about the meta-operator collision thing, S03 says that
: you can't modify with '!' forms that start with '!', and you can't
: modify with '=' forms that end with '='
: jnthn dakkar: Ah, OK, so should probably be an error or some thing for
those.
: * masak submits rakuodbug
I don't see a bug here. First, there's no prohibition on multiple
similar metas anymore. But with regard to the example above, metas
are parsed as their own tokens, and the infix:RR is longer than
the meta R, so should take precedence under LTM. We used to try
to form tokens out of all possible forms of meta, but that resulted
in an explosion, even with restrictions on meta recursion. So we
lifted the restriction and now parse metas separately, albeit
still with the requirement of no whitespace between meta and base op.
Anyway, if there is a tie between a meta and a normal, it tries
the meta first and then backtracks to the normal if the meta
doesn't find a base op. That's how Xop wins against X.
Larry
Re: [perl #65878] Rakudo shouldn't allow metaops with the same modifier twice in a row
On 2009-05-21 Larry Wall la...@wall.org wrote:
: dakkar rakudo: sub infix:R($a,$b) { $a ~ '-' ~ $b }; sub
: infix:RR($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y';
: p6eval rakudo e6b463: OUTPUT«x-yx_y»
: dakkar now, apart from don't do that, what should happen?
: [snip]
: dakkar jnthn: about the meta-operator collision thing, S03 says
: that you can't modify with '!' forms that start with '!', and you
: can't modify with '=' forms that end with '='
Ok, let me try to explain what I was aiming at…
If we have a normal operator, whose spelling is the same as a
meta-modified version of another operator, which one should get
called? The normal (like rakudo does today), or the meta-modified? IN
my example, is the output correct, or should it have been «x-yy-x» ?
I don't see a bug here. First, there's no prohibition on multiple
similar metas anymore. But with regard to the example above, metas
are parsed as their own tokens, and the infix:RR is longer than
the meta R, so should take precedence under LTM.
Ok, so this means that rakudo does the right thing, which looks pretty
sensible to me.
So normal operators will always take precedence against meta-modified
operators. Should there be a way to explicitly say I mean a
meta-operator here? If I write:
sub infix:»ö«($a,$b) { return butterfly between $a and $b }
sub infix:ö($a,$b) { return abs($a-$b) }
how do I make:
say (1,2,3) »ö« (3,4,5)
print:
2 2 2
(apart from doing it the hard way with map, zip, etc)?
--
Dakkar - Mobilis in mobile
GPG public key fingerprint = A071 E618 DD2C 5901 9574
6FE2 40EA 9883 7519 3F88
key id = 0x75193F88
This one's tricky. You have to use imaginary numbers, like
eleventeen ... -- Hobbes
signature.asc
Description: PGP signature
[perl #65878] Rakudo shouldn't allow metaops with the same modifier twice in a row
Larry (): I don't see a bug here. First, there's no prohibition on multiple similar metas anymore. But with regard to the example above, metas are parsed as their own tokens, and the infix:RR is longer than the meta R, so should take precedence under LTM. We used to try to form tokens out of all possible forms of meta, but that resulted in an explosion, even with restrictions on meta recursion. So we lifted the restriction and now parse metas separately, albeit still with the requirement of no whitespace between meta and base op. Anyway, if there is a tie between a meta and a normal, it tries the meta first and then backtracks to the normal if the meta doesn't find a base op. That's how Xop wins against X. I had an inkling this might actually be a non-bug. Rejecting ticket.
