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
Dave Mitchell
February 8, 2021 16:49
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
On Thu, Feb 04, 2021 at 12:22:48PM +0000, Paul "LeoNerd" Evans wrote:
> Oh indeed there is; but the same tension is always present for any
> other feature too. It might vary to different degrees in different
> situations, but whenever adding any feature you always have to consider
> the long-term support implications behind whatever you document as
> being "the thing".
> I often find the way to approach that is to start off trying to *use*
> the newly added feature, imagining it to be added in whatever form I
> would find most convenient to use. That way I have some test cases, and
> a feel for "what would users want to use?" that are made independently
> of how it might be implemented. Hopefully a sufficiently-practical and
> useful interface is not so tightly constrained to its implementation
> that it unduely constrains the shape of that implementation.

I hate and loathe hooks. Each individual proposal seems superficially
reasonable, but added together they gradually make what are supposed to
be the internal details of the perl core more and more exposed and

In general a hook exposes a new part of the perl internals that was
previously allowed to be modified by ourselves any way we want, but now
has to maintain the current behaviour to avoid breaking  any XS code which
hooks into it.

To give an example (one of many): perl's peephole optimiser is hookable;
both for the top-level call which "peepholes" an entire optree, but also
at the recursion level: you can hook each time Perl_rpeep() is called to
follow along an alternative execution path as found in LOGOPs etc.

It's documented - people are told it's there and they can use it, but its
not documented in terms of what perl promises as regards how and when it
will recurse. So people will write XS modules using it based on "what perl
does at the moment". So if perl's behaviour changes, the behaviour of the
XS code may change.

At a trivial level, suppose I want to fix the peephole optimiser in some
way to avoid deeply recursing (and so avoid crashing the stack on deeply
nested and perhaps auto-generated code like A ? B : C ? D : E ....).
Now the fix is harder because I may be changing where and how often the
rpeep hook is called and thus triggering lots of BBC reports for CPAN
modules I've now broken. Or more generally, if in the future I want do to
Brave New World stuff to do with perl compiling - e.g. separate out op
chains into Basic Blocks for better optimisation, or translate to LLVM or
bytecode or whatever - its an albatross around my neck.

Hooks give people the illusion of flexibility and being able to expand
perl in exciting, modern, and dynamic new ways; in reality it's a further
nail in the coffin.

(This is all just my opinion of course :-)

In economics, the exam questions are the same every year.
They just change the answers.

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