Precedence levels and associativity conflicts (Re: class interface of roles)
Larry ():
[...]
The non-chaining precedence level is a bunch non-associative operators
like .. and cmp. Historically, all operators of a particular precedence
level have had the same associativity, so that when you analyze
$a op1 $b op2 $c
you only have to compare op1 with op2 if they're the same precedence, and
given the prededence you don't actually have to look at the individual
ops. What would it mean to have a left-associative op at the same precedence
level as a right-associative op:
$a lefty $b righty $c
Who would win? So generally we try not to mix associativity within a
precedence level.
Short question: what would happen if I as the user would try and
define two operators on the same precedence level, and then try to use
them in the above way? How far would I get?
In other words, I'd do something like this:
my sub infix:lefty is assoc('left') ($a, $b) { $a - $b; }
my sub infix:righty is assoc('right') ($a, $b) { $a - $b; }
say (1 lefty 2 righty 3); # a-ha! will this be -4 or 2 ?
Pugs currently dies on evaluating the last line, explaining to me that
an ambiguous use of a right associative operator occurred. This
might even be a fairly sane behavior. The only alternative I can think
of right now would be to disallow even _declaring_ two operators of
different associativity on the same precedence level... but that kind
of strictitude doesn't sound very perlish.
Kindly,
--
masak
Re: Precedence levels and associativity conflicts (Re: class interface of roles)
Carl Mäsak wrote: The only alternative I can think of right now would be to disallow even _declaring_ two operators of different associativity on the same precedence level... but that kind of strictitude doesn't sound very perlish. That depends on how you phrase the restriction. If you phrase it as all assoc traits that get applied to operators of equivalent precedence must have the same value, you're right; it doesn't sound very perlish. If you phrase it as associativity is a feature of the precedence level, not the operator and adjust syntax accordingly, it's very perlish. The syntax adjustments would go something like this: remove the 'assoc' trait; let people specify an optional assoc value when they use the 'looser' or 'tighter' traits; and require code to look up the operator's precedence in order to modify its associativity. -- Jonathan Dataweaver Lang
Re: Precedence levels and associativity conflicts (Re: class interface of roles)
Jonathan (), Carl (): The only alternative I can think of right now would be to disallow even _declaring_ two operators of different associativity on the same precedence level... but that kind of strictitude doesn't sound very perlish. That depends on how you phrase the restriction. If you phrase it as all assoc traits that get applied to operators of equivalent precedence must have the same value, you're right; it doesn't sound very perlish. If you phrase it as associativity is a feature of the precedence level, not the operator and adjust syntax accordingly, it's very perlish. The syntax adjustments would go something like this: remove the 'assoc' trait; let people specify an optional assoc value when they use the 'looser' or 'tighter' traits; and require code to look up the operator's precedence in order to modify its associativity. While I'm not in a position whence I can tell if your solution is better than the current or not, I definitely like the practice of changing one's model of the world into one where the problem itself simply ceases to exist. :) -- masak
