Mailing List Archive

("process" comment) Re: RFC 0004 - defer {} syntax
Not commenting on the content of the thread, just that this is a good time to suggest that, since this is an "accepted" RFC (assuming so since it has a number, 0004):

* it's a good time to suggest self-contained, high quality comments directed towards the process
* discussions are cool, but who are you (collectively) trying to convince - individuals on p5p, PSC, etc?
* devolving into "threads" is getting back to where things got stuck "before"

As I said before, I thing discussions are cool but the point at which it becomes purely persuasive or debateful in nature, it might be time to switch to compiling a set of well done, self-contained opinions so that PSC or whomever can make a decision based on the "next" step.

I also suggest these opinions be sent directly to PSC (or the main facilitor), but cc'd here for visibility. That would not be an invitation to then pick apart these opinions, but rather to allow others to form their own and if they wish, send their own to the PSC (privately is okay, but again the idea is that these comments be collected and made available for future benefit in addition to allowing the RFC facilitation to proceed as efficiently as possible).

I also recommend individuals be encouraged to submit as few as possible and not refer directly to other opinions, but focus on their specific case and providing supporting words, examples, references, etc.

In my mind a "successful" RFC process is one where:

a) pre-RFC is sent; it's accepted or not (clearly) [limited to no "discussion" on it other than by PSC]
b) on acceptance, RFC author provides a final "RFC" proposal but only entertains discussion points of clarifications (e.g., questions other have)
c) then the "comment" process is more a collection of opinions sent formally to the PSC
d) discussions will happen but PSC should not have to track them

Lastly, back to the original point - if your idea is "good" it will defend itself and gain supporters; the same applies to anyone "against" an idea or RFC; if your reasoning is "good" it will also defend itself.

Sorry, just trying to help redirect things a bit since I myself have a hard time following all of these different threads; arguments; counter arguments; etc.

Cheers,
Brett

??????? Original Message ???????

On Thursday, June 17th, 2021 at 6:40 AM, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Thu, 17 Jun 2021 12:16:01 +0300
>
> Sergey Aleynikov sergey.aleynikov@gmail.com wrote:
>
> > - why invent a new verb for already existing semantic?
> > - what do all current CPAN implementations lack, thus requiring this
> >
> > feature?
> > - why has this to be a core feature, compared to yet another CPAN
> >
> > module?
> > - why any existing module can't be bundled with Perl, achieving this
> >
> > functionality?
>
> First I'm going to quote Nicholas Clark's lovely reply to this on a
>
> different thread:
>
> > > Trouble is, that Perl is a Turing complete language. Meaning that
> > >
> > > any possible new feature that could be proposed can already be
> > >
> > > implemented with existing functionality.
>
> > > So arguing against a new feature because it is already possible is,
> > >
> > > well, tautological.
>
> Secondly I'm going to point out a few things:
>
> - Aside from Syntax::Keyword::Defer, every other solution to this in
>
> CPAN all wraps the deferred code in an anon sub. Core's defer, and
>
> S-K-D do not. This has many effects but means, for example, that @_
>
> behaves "unexpectedly"; and caller() gets confused.
> - Additionally, all of the CPAN implementations besides S-K-D
>
> implement the deferred code by either DESTROY on an object, or using
>
> SAVEDESTRUCTOR_X to call_cv() an anon CV later on. In both of these
>
> cases, the deferred code could throw an exception, which by
>
> necessity is non-fatal to the surrounding code and is either
>
> ignored, or simply printed with a warning. S-K-D, and my core
>
> implementation, do not do this. They nest an inner RUNOPS loop,
>
> meaning that exceptions behave "as expected" - a `die` inside
>
> `defer` is thrown to the caller much like a `die` anywhere else.
> - All of the CPAN implementations, including S-K-D, have unfortunate
>
> interactions between next/last/redo (the "loopex" ops) and the defer
>
> block. A true core implementation can forbid these.
>
> while(1) {
>
> defer { last }
>
> }
>
> will cause core to die with "Unable to 'last' out of a defer block"
>
> whereas, any of the CPAN versions will either permit it but cause
>
> further confusions, or outright segfault the interpreter.
>
> In summary, all of the CPAN solutions are worse than core can
>
> provide, because core can do things no CPAN solution (including
>
> pluggable keywords) can do. Specifically in this case, the core
>
> solution adds a whole new context stack type (CXt_DEFER) that the
>
> loopex ops can inspect to complain about trying to next/last/redo
>
> out of. Also `goto`.
>
> Thirdly, to answer your final point about why not just bundle the syntax
>
> module with core perl: If the module were able to perfectly perform
>
> the same work as core perl, this could technically work. However, note
>
> above that it can't (CXt_DEFER). But even if this were possible, I
>
> don't think that is a very nice way forward. The entire point of
>
> pluggable syntax modules is to allow CPAN-based experimentation of new
>
> features (Function::Parameters became feature 'signature';
>
> Syntax::Keyword::Try became feature 'try'). The successful end-goal of
>
> that experimentation is promoting the feature to becoming true core
>
> syntax. There is no point in core shipping a syntax plugin module,
>
> because core can just do core things.
>
> This third point will always be my answer whenever anyone says "well
>
> why can't we just ship that syntax module with core".
>
> --
>
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
>
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/