On Thu, 4 Feb 2021 01:21:22 +0100 Leon Timmermans <fawaka@gmail.com> 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 enum PERLOP_PRECEDENCE { PRECEDENCE_TERM = 10, PRECEDENCE_CMP = 20, PRECEDENCE_EXPR = 30, }; 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 leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous