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. -- 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 | Thread Next