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:
Yuki Kimoto
Date:
February 8, 2021 23:28
Subject:
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
CAExogxNmA9Z2=_CVJk+F7yQaO_Z9fUTVWTczy1AVknhmAU9sUg@mail.gmail.com
As for the order, I feel that optimization should be prioritized
This is because optimization after adding syntax becomes more difficult.
I want to know the following optimization more.
> separate out op
> chains into Basic Blocks for better optimisation
2021年2月9日(火) 3:25 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>:
> 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 <davem@iabyn.com> 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
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>
Thread Previous
|
Thread Next