Rakudo shouldn't allow metaops with the same modifier twice in a row

[p6rt]

Migrated from rt.perl.org#65878 (status was 'rejected')

Searchable as RT65878$

[p6rt]

From @masak

\ rakudo​: sub infix​:\($a,$b) { $a ~ '-' ~ $b }; sub infix​:\($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y'; \ rakudo e6b463​: OUTPUT«x-y␤x_y␤» \ now, apart from "don't do that", what should happen? \ dakkar​: "don't do that" only applies after you've found out that what happens is really not what you want. :) \ 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 \ dakkar​: me too. \ dakkar​: Your definition just happens later and wins atm, but it's a little more ty accident than it perhaps should be. \ depends on whether the auto-defined RR is considered a real sub. then it should perhaps complain. \ Well, it's a real sub. Question is if we make it a multi... \ But in that case we woulda got a failure here. \ I'm not sure. The spec may have answers. \ But I don't remember seeing any. \ 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 '=' \ dakkar​: Ah, OK, so should probably be an error or some thing for those. * masak submits rakuodbug

[p6rt]

From @TimToady

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 > : : : \ rakudo​: sub infix​:\($a,$b) { $a ~ '-' ~ $b }; sub : infix​:\($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y'; : \ rakudo e6b463​: OUTPUT«x-y␤x_y␤» : \ now, apart from "don't do that", what should happen? : \ dakkar​: "don't do that" only applies after you've found out : that what happens is really not what you want. :) : \ 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 : \ dakkar​: me too. : \ dakkar​: Your definition just happens later and wins atm, but : it's a little more ty accident than it perhaps should be. : \ depends on whether the auto-defined RR is considered a real : sub. then it should perhaps complain. : \ Well, it's a real sub. Question is if we make it a multi... : \ But in that case we woulda got a failure here. : \ I'm not sure. The spec may have answers. : \ But I don't remember seeing any. : \ 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 '=' : \ 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​:\ 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

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From @masak

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​:\ 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.

[p6rt]

From [Unknown Contact. See original ticket]

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​:\ 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.

[p6rt]

@masak - Status changed from 'open' to 'rejected'

[p6rt]

From @dakkar

On 2009-05-21 Larry Wall \larry@&#8203;wall\.org wrote​:

: \ rakudo​: sub infix​:\($a,$b) { $a ~ '-' ~ $b }; sub : infix​:\($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y'; : \ rakudo e6b463​: OUTPUT«x-y␤x_y␤» : \ now, apart from "don't do that", what should happen? : [snip] : \ 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-y␤y-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​:\ 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 - \   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

[p6rt]

From @TimToady

On Thu, May 21, 2009 at 07​:20​:57PM +0200, Gianni Ceccarelli wrote​: : On 2009-05-21 Larry Wall \larry@&#8203;wall\.org wrote​: : > : \ rakudo​: sub infix​:\($a,$b) { $a ~ '-' ~ $b }; sub : > : infix​:\($a,$b) { $a ~ '_' ~ $b }; say 'x' R 'y'; say 'x' RR 'y'; : > : \ rakudo e6b463​: OUTPUT«x-y␤x_y␤» : > : \ now, apart from "don't do that", what should happen? : > : [snip] : > : \ 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-y␤y-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​:\ 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