Front page | perl.perl5.porters |
Postings from February 2021
Hi *Hugo*: How will we set the priority of the *infix* operators? Just so we are all on the same page: https://en.wikipedia.org/wiki/Infix_notation On Thu, Feb 4, 2021 at 1:53 AM <hv@crypt.org> wrote: > "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. > > I've always been a fan of such hooks, but @iabyn has often responded > to suggestions of more with the cogently argued point that they bind > the hands of core in perpetuity, and thus make impossible changes that > would otherwise be able to benefit all users. > > There's a definite tension there, so I think one would need to be able > to clearly make the case that the point of hooking is one that we won't > want to change in any reasonably likely future in a way that the > existence of the hook would make more problameatic. > > Beyond that, I'm all for them, and I'll let Dave make his arguments > for himself. :) > > Hugo > -- Thanks, Phil <https://metacpan.org/author/PRBRENAN> Philip R Brenan <https://metacpan.org/author/PRBRENAN>Thread Previous | Thread Next