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
Paul "LeoNerd" Evans
February 8, 2021 18:25
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
TL;DR summary:
  I accept the breakage-guarantee point, but I want a way to iterate
  new designs faster than bleadperl's yearly release cycle.

On Mon, 8 Feb 2021 16:49:26 +0000
Dave Mitchell <> wrote:

> 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
> ossified.
> 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 :-)

Yes; those are all reasonable counter-arguments against the idea of
adding it. It's always a tricky two-sided question.

Perhaps I can add some more motivation.

I am quite interested in experimenting with some new equality operator
ideas I have - equ and === - which would treat undef as their own
special value; so `undef equ ""` and `undef === 0` are both false.

While I -could- do this purely within bleadperl itself, that is at
least one if not two orders of magnitude slower to iterate and
experiment on a design in real production code (i.e. beyond toy
examples in in-core unit tests).

I have been very fortunate that `PL_keyword_plugin` and the `OP_CUSTOM`
mechanisms exist, because they have allowed me to make CPAN modules to
experiment with

 * try/catch [Syntax::Keyword::Try], now moved to core ;)

 * FINALLY [Syntax::Keyword::Finally]

 * async/await [Future::AsyncAwait]

 * class/has/method [Object::Pad]

 * dynamically [Syntax::Keyword::Dynamically]

 * and several other ideas I have yet to publish.

In many of these cases, I am actually helping support those features
in Real Production Code, deployed for real in actual money-making
applications for clients I work for. That has been possible *only*
because those can be iterated on entirely in CPAN modules. I can deploy
code on a Monday, take feedback over the next few days, and adjust and
change the module for a second update later in the same week even.

This velocity is simply impossible for bleadperl's yearly release cycle
to manage. If I was forced to develop those features only in core, then
it is highly doubtful any of it would exist already today - certainly
nothing as nontrivial as async/await would. I merged try/catch into
bleadperl last week by basically copying what Syntax::Keyword::Try
does. Without the syntax hook that would not have been possible.

That all said, I do accept that there is a tradeoff here. Personally,
I'd be quite happy to add code for `PL_operator_plugin` into bleadperl
and not even bother documenting it or telling anyone about it, purely
so that I could develop some syntax modules myself. I could test them
out on my own systems to experiment with the ideas, as a high-velocity
testbed for getting the idea stable enough to add to core for real.
I suspect others may not be happy if I did this though ;)

Could we find a compromise position somehow? Strongly Worded
Documentation, a ./Configure-time guard, something to make such a
feature well and truely "we make no guarantees whatsoever. We will
absolve all responsibility of BBC to the point that if your module
breaks we will point and laugh"?

In -theory- perl5-porters are supposed to be able to support uses of
the existing `PL_keyword_plugin` mechanism. In -practice- who is
actually using that on CPAN right now? I know of 5 nontrivial modules
of my own, plus 2 by MAUKE (who hasn't been seen around in maybe three
years now), and a few by ZEFRAM (who is similarly AWOL). In practice, I
am not personally aware of any other CPAN author who is even using the
existing hooks, other than myself. I suspect any newly-added hooks
would follow a similar pattern.

I personally would be happy to add and use a new hook, well aware that
if in future you break anything I'm using it for, you can all point and
laugh at me. 

Paul "LeoNerd" Evans      |  |

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