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
Leon Timmermans
February 4, 2021 00:22
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
On Thu, Feb 4, 2021 at 12:01 AM 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.

How would that work with regard to precedence?


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