On Thu, Feb 4, 2021 at 12:01 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote: > > For that matter, how do we feel about the wider topic of more > customisation hooks in other parts of the interpreter? Right now we > have pluggable keywords, and custom opcodes that can implement them. If > we add custom context stack types as well that starts to give us a lot > of power. > > One more thing I would like is some ability to hook into other bits of > the parser than the PL_keyword_hook currently gives. Namely, I would > like a hook to be able to implement infix operators. > > The lack of such a hook meant that I wasn't able to experiment with > `isa` as a CPAN module but had to dive straight into an in-core > attempt. This lack also means I am unable to experiment with any other > sorts of infix operators, such as some new thoughts on string or number > equality I have, or the oft-requested `ELEM in LIST` operator. > > I have a vague design on a similar idea to the current PL_keyword_hook > mechanism that would be able to provide this, and allow CPAN > module-based experimentation of new infix operator syntax. As we have > already seen with the keyword API as it stands, being able to > experiment with new ideas on CPAN leads to a much faster turnaround > time in being able to stablise a new idea, for eventual movement into > Perl core for real. It would be lovely to be able to offer that for > operators as well. How would that work with regard to precedence? LeonThread Previous | Thread Next