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 | Thread Next
Philip R Brenan
February 4, 2021 02:02
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
Hi *Hugo*:

How will we set the priority of the *infix* operators?

Just so we are all on the same page:

On Thu, Feb 4, 2021 at 1:53 AM <> wrote:

> "Paul \"LeoNerd\" Evans" <> 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


Phil <>

Philip R Brenan <>

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