develooper Front page | perl.perl5.porters | Postings from February 2021

Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]

Thread Previous
Paul "LeoNerd" Evans
February 4, 2021 12:19
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
On Thu, 4 Feb 2021 01:21:22 +0100
Leon Timmermans <> wrote:

> How would that work with regard to precedence?

I had two thoughts about this. Either there would be not just one hook
but in fact a few hooks, loosely named to suggest whereabouts in the
precedence order they sit:

  PL_termop_plugin  # binds very tightly, eg. like *
  PL_cmpop_plugin   # binds at the same level as 'eq' and other
                    #   comparison ops
  PL_exprop_plugin  # binds much looser, e.g. like "or"

or else just a single hook that gets passed in the precedence at which
we're currently looking; something like

  (*PL_operator_plugin)(pTHX_ I8 prec, ...);

where prec is some number taken from maybe


plenty of gaps there to consider adding more later. The idea here being
that you'd only respond at the appropriate precedence level.

I'd only start off by suggesting at most these three levels. The more
levels we actually provide, the more it constrains our implementation
to support them, and the more potential we create that people can make
new operators with unclear rules.

There may additionally be scope in the implementation to be able to
throw compiletime warnings if people actually write syntax involving
more than one custom operator without parens. Even if perl itself is
happy with the rules, the syntax might be unclear to readers unfamiliar
with the syntax, so encouraging authors to put parens in makes the
precedence more obvious.

Paul "LeoNerd" Evans      |  |

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About