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
From:
hv
Date:
February 4, 2021 01:52
Subject:
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
202102040138.1141cYP09639@crypt.org
"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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About