Mailing List Archive

From the keyboard of Paul "LeoNerd" Evans [17.06.21,20:49]:

> On Thu, 17 Jun 2021 14:35:27 -0500
> David Nicol <davidnicol@gmail.com> wrote:
>
>> really? you've said "defer <CODEREF>" repeatedly
>
> I hope I haven't ever said that. I have mentioned `defer { BLOCK }`.
>
> Blocks aren't coderefs.
>
> E.g. consider the way that if(COND) { BLOCK } is not a coderef.
>
> It's verymuch not a coderef - `caller()` can't see it, it doesn't get
> its own `@_`, you can't `return` from it, etc...

Well, a BLOCK passed to a sub is very likely a CODEREF - at least inside
the subroutine:

sub foo (&) {
say $_[0];
$_[0]->();
}
foo { say "calling foo()" }
__END__
CODE(0x55b2e63b2440)
calling foo()

So, a flow control block attached to if, for, while etc is not a CODEREF,
but one passed to a function is, e.g. sort { $b <=> $a }, also with map
although slightly different:

$f = sub { $_ x 2 };
say for map $f->(), qw(a b c);
__END__
aa
bb
cc

And since "defer" is a function, it takes a coderef.

0--gg-

--
_($_=" "x(1<<5)."?\n".q?/)Oo. G?\ /
/\_?/(q /
---------------------------- \__(m.====?.(_("always off the crowd"))."?
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

On Thu, 17 Jun 2021 22:16:35 +0200 (CEST)
shmem <gm@qwurx.de> wrote:

> And since "defer" is a function, it takes a coderef.

The entire point here is that adding it as real syntax means defer
*isn't* a function. It's real native syntax, as real as

if(COND) { BLOCK }

while(COND) { BLOCK }

use feature 'try';
try { BLOCK } catch($VAR) { BLOCK }

As such, it can operate on a block that isn't implemented as a coderef.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Thu, 17 Jun 2021 at 00:16, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

>
> be a SHOUTY PHASER BLOCK. All the SHOUTY PHASER BLOCKS are declarations,
> activated by their mere presence at compiletime, whereas `defer {}` is
> a statement which only takes effect if dynamic execution actually
> encounters it. The p5p mailing list and the CPAN module's RT queue both
> contain various other rejected naming ideas, such as UNWIND, UNSTACK,
> CLEANUP, to name three.
>
>
Unrelated note to this RFC, just observation:

From discussion about trim uppercase version of name seems better
alternative to me.
words like __PACKAGE__, AUTOLOAD, or taken from Ovid's Corinna, ADJUST,
these
tokens are not phaser and yet still there is a reason to have them
uppercase.

Maybe there should be some guideline when to use uppercase and when
lowercase.

On Thu, 17 Jun 2021 22:32:46 +0200
Branislav Zahradník <happy.barney@gmail.com> wrote:

> words like __PACKAGE__,

__PACKAGE__, along with __FUNC__, __LINE__, __FILE__, etc.. are all
dunder-shouties, as they are constants. The parser literally replaces
them with a string (or number, in the case of __LINE__):

$ perl -MO=Deparse -ce 'my $file = __FILE__';
my $file = '-e';

> AUTOLOAD

AUTOLOAD is one of those weird things that probably should be specified
with `sub`; it's supposed to be

sub AUTOLOAD {
...
}

just that the parser lets you get away without the `sub`.

> or taken from Ovid's Corinna, ADJUST

Ah; but ADJUST _is_ a phaser. It's a block of code whose _mere
presence at compile time_ is sufficient:

LOOP: {
class AClass {
has $slot;

last LOOP;

ADJUST { $slot = 123; }
method greet { say "Slot is $slot" }
}
}

AClass->new->greet;
Slot is 123

Even though the line on which the ADJUST phaser was declared was never
dynamically reached (because we `last`ed out before it got there),
nevertheless the mere declaration of it was sufficient for it to be
active; much like the subsequent `method`.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Thu, Jun 17, 2021 at 9:37 PM David Nicol <davidnicol@gmail.com> wrote:

> really? you've said "defer <CODEREF>" repeatedly, and it sounded like the
> message I was responding to brought up the question of if defered block
> would happen always, or only when the defer keyword was encountered during
> run-time flow.
>

If that was in reference to my message, I was not asking about defer (the
RFC was clear to me on that), but on phasers as such, a Perl 5 context. My
impression was we had different ideas about what that word means in a Perl
5 context.


Eirik

I read the content of the Github issue again.

defer block is like END block that runs at the end of the scope, isn't it?

I feel this syntax is natural for Perl users now.

It seems that some pseudo-things are implemented on CPAN as well.

Op 18-06-2021 om 03:16 schreef Yuki Kimoto:
> I read the content of the Github issue again.
>
> defer block is like END block that runs at the end of the scope, isn't it?
>
> I feel this syntax is natural for Perl users now.
>
> It seems that some pseudo-things are implemented on CPAN as well.
>

Yes and no. Yes, it's like that, because it runs on the end of a scope,
like END does at the end of the run. No, it's not like that as END
blocks always run when compiled, but defer is a statement that must be
executed for it to have it's effect.


HTH,

M4

so what's wrong with just squidding it out in long form?

sub abcdefg {
my $defer;
...
my_predicate and $defer = sub {warn "MY_PREDICATE WUZ TROO!\n"};
...
$defer and &$defer;
$retval;
}

On Fri, Jun 18, 2021 at 3:55 AM Martijn Lievaart <m@rtij.nl> wrote:

> Op 18-06-2021 om 03:16 schreef Yuki Kimoto:
> > I read the content of the Github issue again.
> >
> > defer block is like END block that runs at the end of the scope, isn't
> it?
> >
> > I feel this syntax is natural for Perl users now.
> >
> > It seems that some pseudo-things are implemented on CPAN as well.
> >
>
> Yes and no. Yes, it's like that, because it runs on the end of a scope,
> like END does at the end of the run. No, it's not like that as END
> blocks always run when compiled, but defer is a statement that must be
> executed for it to have it's effect.
>
>
> HTH,
>
> M4
>
>
>

--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

On Fri, Jun 18, 2021 at 6:08 PM David Nicol <davidnicol@gmail.com> wrote:

>
>
> so what's wrong with just squidding it out in long form?
>
> sub abcdefg {
> my $defer;
> ...
> my_predicate and $defer = sub {warn "MY_PREDICATE WUZ TROO!\n"};
> ...
> $defer and &$defer;
> $retval;
> }
>

That won't run if scope is exited during the second ellipsis.

Whereas the defer "enqueues a block of code for later execution, when
control leaves its surrounding scope for whatever reason", so as long as
the defer statement is reached, the block will eventually run. (Well,
untimely program termination will prevent it, I guess.)


Eirik

On Fri, Jun 18, 2021 at 12:28 PM Eirik Berg Hanssen <
Eirik-Berg.Hanssen@allverden.no> wrote:

>
>
> On Fri, Jun 18, 2021 at 6:08 PM David Nicol <davidnicol@gmail.com> wrote:
>
>>
>>
>> so what's wrong with just squidding it out in long form?
>>
>> sub abcdefg {
>> my $defer;
>> ...
>> my_predicate and $defer = sub {warn "MY_PREDICATE WUZ TROO!\n"};
>> ...
>> $defer and &$defer;
>> $retval;
>> }
>>
>
> That won't run if scope is exited during the second ellipsis.
>
> Whereas the defer "enqueues a block of code for later execution, when
> control leaves its surrounding scope for whatever reason", so as long as
> the defer statement is reached, the block will eventually run. (Well,
> untimely program termination will prevent it, I guess.)
>

Yes, the primary usecase for scope guards is to run regardless of whether
the scope is normally exited. Abnormal scope exits include exceptions, loop
control flow, and returning from a subroutine, among more esoteric options.

-Dan

very true. The rest of the single exit point pattern is having some
discipline about not exiting except via it.



>> Whereas the defer "enqueues a block of code for later execution, when
>> control leaves its surrounding scope for whatever reason", so as long as
>> the defer statement is reached, the block will eventually run. (Well,
>> untimely program termination will prevent it, I guess.)
>>
>
> Yes, the primary usecase for scope guards is to run regardless of whether
> the scope is normally exited. Abnormal scope exits include exceptions, loop
> control flow, and returning from a subroutine, among more esoteric options.
>

On Thu, Jun 17, 2021 at 12:16:19PM +0000, mah.kitteh via perl5-porters wrote:
>
> ??????? Original Message ???????
>
> On Thursday, June 17th, 2021 at 6:58 AM, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
> > Overall here I'm seeing a lot of feedback about the idea, but none
> >
> > really about the way I have documented it. I thought that was the point
> >
> > of this pre-RFC "just send an email" part of the process.
> >
> > Since folks are engaging with the substance of the document, I will
>
> Sounds like a good idea to me. I suppose I was wrong; seems this was actually a pre-RFC (was not clear so that needs to be a tweak in the process - I have been trying to follow along).

Right. So. You're on the money here. PSC thinks:

Start the process by mailing your "elevator pitch" to the list.

Specifically, send a short mail with 4 paragraphs that say:

1: Here is a problem
2: Here is the syntax that I'm proposing
3: Here are the benefits of this
4: Here are potential problems

(And if a "paragraph" is 1 sentence, great)


and that should be enough to make it obvious whether the idea is

0) worth drafting an RFC for
1) better on CPAN first
2) "nothing stops you putting it on CPAN, but it doesn't seem viable"


ie don't start out by taking the RFC template and attempting to fill it in.
Start with the summary above.


[.for now this is e-mail, and to this list. Once we've got the process
bootstrapped, it might turn into an "issue" template for the RFC repository.
But not yet]

> Question for PSC: what's the indicator for submitting such a request? Could this have been done earlier in the "discussion"? What sort of discussions/comments are even appropriate for a pre-RFC? Seems to me as long as it's "well formed" and "high quality" the burden for creating a PR should be pretty low, since this is not the stage where the details I've been seeing in this thread are to be 'hashed out'.
>
> >
> > judge that I've got the first draft "about right", and therefore add it
> >
> > to the RFCs repo:
> >
> > https://github.com/Perl/RFCs/pull/2
>
> So now I'll ask the RFC mediators; what's the next step here?

Um, well, technically the previous step was to mail the list with an idea,
which got skipped. (But I get why)

Also, according to my sketch of the "future" plans, that RFC draft should
have been an "Exploratory" RFC with a self-assigned ID. It shouldn't have
assumed that it would be 0004. (But I get why)


From this, I realise that "Draft" as a status name is a bad idea.
(Much like "Approved" isn't a name, to avoid confusion)

The status changes "Draft"/Provisional/Accepted/Implemented/Shipped/Stable
and what they stand for still makes sense - we just need a better name.


But, I was really pleased to read that RFC - Paul wrote an RFC that looks
like the style of document I was envisaging, with the right level of detail,
first time.

Until now I'd been the only person writing these things, so I didn't know if
we'd got the concept all wrong. It *might* still turn out that we have the
basic plan wrong, but right now it looks like it's still the right
direction, and it's more details that we need to iron out, not "redo from
start".


Anyway, what happens *next* is that I do the editorial checks on his "draft"
and put it in the repository (along with some other fixes that need doing)
However, I'm running out of time, and might not get a chance to do this
until tomorrow morning, or maybe even Monday morning. (Sorry. Life)

Also, PSC think that the status is now "Provisional" - ie we got here:

idea
|
v
mail p5p
|
better | rejected
on <-------?-------> with
CPAN | reasoning
v
Draft RFC
"we think this idea is worth exploring"
(Help us figure out how this will work)
|
v
Provisional RFC
"we think this idea is worth implementing"
(We have a firm idea of what we want to do)


because we have a pretty firm idea of what we want to do.

Nicholas Clark

On Wed, Jun 16, 2021, at 6:15 PM, Paul "LeoNerd" Evans wrote:
> # defer {} syntax

I'll be brief. First off, thanks, Paul, for doing a good job at dealing with this thread's ups and downs.

This seems like a reasonable proposal about which I have no strong feelings (yet). But I do have a question:

This is similar to, but not the same as, UNITCHECK. I would surely use this more often than I have used UNITCHECK, and I am definitely not here to say that defer is a phaser or redundant.

But when unitcheck was introduced, I remember thinking clearly and repeatedly that I'd have used it far often if it had been possible to inject the unitcheck upward one scope. Honestly, I'd have to do a fair bit more thinking about it to remember the use cases I had in mind. But you suggest (I think *very* hopefully) that we could eventually get away from timely destruction if we had better defer blocks. I think often we'd like defer blocks to be produced by reusable code, which does hint toward the idea of "defer this until my calling scope is complete."

Do you think this is an area in which we should consider nudging the capabilities of this proposal?

--
rjbs

On Sat, 19 Jun 2021 22:41:24 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> But you suggest (I think *very* hopefully) that we could eventually get away from timely destruction if we had better defer blocks. I think often we'd like defer blocks to be produced by reusable code, which does hint toward the idea of "defer this until my calling scope is complete."

I understand that this was purely hypothetical, but nevertheless, I
want to make it clear that deterministic destruction is a core language
feature, more core than much of the syntax, and we can't remove it
without breaking pretty much everything. It isn't just a quirk of the
implementation.

RAII can't be implemented without deterministic destruction and
deterministic destruction can't be implemented without some kind of
object ownership mechanism. In Perl's case, it's reference counting.

Without RAII, there will be no automatic file closing, objects won't
have the ability clean-up after themselves. Languages based on pure
tracing garbage collection don't have those things. There's no cheat
code, it's impossible to implement. That's the reason why GC languages
have invented workarounds such as "try-with-resources" (Java), "using"
(C#) or, well, "defer".

To understand the problem with replacing deterministic destruction with
injectable defer blocks, let's imagine that open(), instead of returning
a refcounted filehandle with a destructor, injects a defer block to the
caller. The only reasonable thing that block could do is to close the
file at the end of the scope containing the open() call. That means it
would be impossible to pass the filehandle to the outer scope, e.g. by
"return". That's not good.

On Thu, 17 Jun 2021 at 20:24, Arne Johannessen <arne-9544@thaw.de> wrote:

> Ben Bullock <benkasminbullock@gmail.com> wrote:
> >
> > I can see an advantage from being able to run defers conditionally.
>
> consider:
>
> defer if EXPR { ... }
> vs:
> defer { ... if EXPR }
>
> The second form is already allowed by the syntax proposed in this RFC, so
> the benefit of also allowing the first form seems to be little.
>

I have not expressed any opinion about that.

use feature 'say';
use Syntax::Keyword::Defer;
while (1) {
if (1) {
defer {
say "A";
}
say "B";
}
say "C";
last;
}

prints

B
A
C

My suggestion is that it might be preferable to run the defer outside the
scope of the if block, so the above would print

B
C
A

I suggested this because I can't see how running a deferred block of code
at the end of an "if" block would be useful in practice, since, for example
there is no "next" or "last" which makes it possible to leave the if block
early, whereas being able to conditionally stack defers probably would be
useful.

On Sun, 20 Jun 2021 19:51:10 +0900
Ben Bullock <benkasminbullock@gmail.com> wrote:

> I suggested this because I can't see how running a deferred block of
> code at the end of an "if" block would be useful in practice,

The clean "mental model" of how it operates.

"defer {} runs its code when we hit the next nested }"

As opposed to

"defer {} runs its code when we hit the next nested } that wasn't an
if{} or elsif{} or unless{}, or maybe we'd consider adding do {} to
that list since you can't next out of them and what about match/case
blocks and ...."

`defer {}` runs at the same time that `my` variables go out of scope,
and `local` modifications get undone. This is by design to make it
simpler to learn and understand.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sat, 19 Jun 2021 22:41:24 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> But when unitcheck was introduced, I remember thinking clearly and
> repeatedly that I'd have used it far often if it had been possible to
> inject the unitcheck upward one scope. Honestly, I'd have to do a
> fair bit more thinking about it to remember the use cases I had in
> mind. But you suggest (I think *very* hopefully) that we could
> eventually get away from timely destruction if we had better defer
> blocks. I think often we'd like defer blocks to be produced by
> reusable code, which does hint toward the idea of "defer this until
> my calling scope is complete."
>
> Do you think this is an area in which we should consider nudging the
> capabilities of this proposal?

An exciting question. There's two parts to the answer:

On the question of how to spell the syntax, I could imagine if we're
going into the realm of core-provided namespaced functions and keywords
(e.g. previous discussions on `string::trim` and `ref::type`) I could
imagine an uplevel:: space for doing that kind of thing:

sub wibble {
uplevel::defer { say "This runs after Hello" }
}

{
wibble();
say "Hello";
}

As to implementation, I have no idea how to create this. `defer {}`'s
current implementation is just to use SAVEDESTRUCTOR_X() which pushes
to the same savestack as things like variable scope clearing and
`local` uses. That's strictly a stack, and you can't splice into it
lower down. There have variously been times I have wanted such
an ability, but equally other times (most notably while implementing
async/await) when I have been thankful for its absence.

I don't think I want to add this to the main body of the current
proposal, but I can at least add a note in "future direction" to
suggest that such an extension might become useful.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sun, Jun 20, 2021, at 8:22 AM, Paul "LeoNerd" Evans wrote:
> I don't think I want to add this to the main body of the current
> proposal, but I can at least add a note in "future direction" to
> suggest that such an extension might become useful.

Thanks, sounds good. (The proposal clearly has value without this creeping feature, after all.)

--
rjbs

2021-6-18 17:55 Martijn Lievaart <m@rtij.nl>:

> Op 18-06-2021 om 03:16 schreef Yuki Kimoto:
> > I read the content of the Github issue again.
> >
> > defer block is like END block that runs at the end of the scope, isn't
> it?
> >
> > I feel this syntax is natural for Perl users now.
> >
> > It seems that some pseudo-things are implemented on CPAN as well.
> >
>
> Yes and no. Yes, it's like that, because it runs on the end of a scope,
> like END does at the end of the run. No, it's not like that as END
> blocks always run when compiled, but defer is a statement that must be
> executed for it to have it's effect.
>
>
> HTH,
>
> M4
>
>
>
Martijn, thank you.

How much does defer block affect current performance of Perl?

On Mon, 21 Jun 2021 at 07:55, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> How much does defer block affect current performance of Perl?
>

The module is available on CPAN:

https://metacpan.org/pod/Syntax::Keyword::Defer

so this would be the best place to start if there are specific benchmarks
you would like to try.

Addition of the keyword should have no measurable impact on existing code.

Performance is generally faster than the equivalent
create-instance-and-hook-DESTROY functionality provided by modules such as
Scope::Guard.

On Sun, 20 Jun 2021 at 21:09, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Sun, 20 Jun 2021 19:51:10 +0900
> Ben Bullock <benkasminbullock@gmail.com> wrote:
>
> > I suggested this because I can't see how running a deferred block of
> > code at the end of an "if" block would be useful in practice,
>
> The clean "mental model" of how it operates.
>
> "defer {} runs its code when we hit the next nested }"
>
> As opposed to
>
> "defer {} runs its code when we hit the next nested } that wasn't an
> if{} or elsif{} or unless{}, or maybe we'd consider adding do {} to
> that list since you can't next out of them and what about match/case
> blocks and ...."
>

Thank you for responding.

"next" and "last" within if statement blocks go to the surrounding loop
block rather than the if block. Similarly "return" in an "if" block returns
from the function rather than jumping out of the if block. I don't see
anyone complaining that that return or next or last do not provide a clean
mental model.

What I find confusing is that, as far as I know, there is not an obvious
way to exit the if{} without actually getting to the end of it, so

if (something) {
defer {
cleanup;
}
do something;
now do the deferred cleanup.
}

doesn't offer an advantage over

if (something) {
do something;
cleanup;
}

I went back and checked, and I've actually said this in all of the messages
I've sent on this thread, and so far nobody has pointed out the mistake in
my understanding. Is there some way of sneaking out of if{} without
arriving at the end of the code?

If "defer" is there to catch a "return" statement in the if block, then why
does "defer" need to be associated with the end of the if block? It could
just as well be associated with the end of the function for that case.
Similarly if it's meant to catch a "next" statement for an enclosing loop.
In both cases the scope which you are guarding is bigger than the if block,
it is either the function scope for the "return", or the loop scope for the
"next".

So I can't see what benefit there is in being able to defer to the end of
an if block scope. Did I miss something obvious?

It might be easier to understand for some people if set up this way, but
for me it was quite confusing why the defer would need to be run at the end
of if {}.

On Mon, 21 Jun 2021 at 09:36, Ben Bullock <benkasminbullock@gmail.com>
wrote:

> So I can't see what benefit there is in being able to defer to the end of
> an if block scope. Did I miss something obvious?
>
> It might be easier to understand for some people if set up this way, but
> for me it was quite confusing why the defer would need to be run at the end
> of if {}.
>

Because it happens when leaving scope - any scope, could be
if/while/try/catch/do...while 0/eval/bare block, they're all treated the
same, and this behaviour already applies for lexical scoping:

Anything introduced in the if() block - including `if(my
$variable_scoped_to_if_statement = ...)` - goes out of scope at the end of
the if() block.

Scope::Guard also triggers the guard sub when leaving the scope of the if()
block, rather than happening at some later point.

Unless you're proposing a change to that behaviour as well - something that
would cause a lot of breakage! - then having defer behave differently
introduces unnecessary consistency.

If you want something to execute in the parent scope, that can be done by
putting the defer above the if() statement. How would the following be
implemented with your suggested change in behaviour?

if(condition) {
open my $fh, '>', 'output' or die;
defer { $fh->close and send_email_from_file('output') }
... arbitrary code which may include next/return/die/goto ...
}
open my $fh, '>', 'output' or die;
...

On Sun, Jun 20, 2021, at 9:36 PM, Ben Bullock wrote:
> What I find confusing is that, as far as I know, there is not an obvious way to exit the if{} without actually getting to the end of it, so
>
> if (something) {
> defer {
> cleanup;
> }
> do something;
> now do the deferred cleanup.
> }
>
> doesn't offer an advantage over
>
> if (something) {
> do something;
> cleanup;
> }

Consider that "do something" might throw an exception.

--
rjbs

On Mon, Jun 21, 2021 at 3:37 AM Ben Bullock <benkasminbullock@gmail.com>
wrote:

> I went back and checked, and I've actually said this in all of the
> messages I've sent on this thread, and so far nobody has pointed out the
> mistake in my understanding. Is there some way of sneaking out of if{}
> without arriving at the end of the code?
>

Yes? Plenty of ways: An exception may sneak out (all the way to the
first dynamically enclosing eval or similar); a return may sneak out (all
the way out of the subroutine call); a next/last/redo may sneak out (all
the way out of the first dynamically enclosing loop with matching label, if
given); a goto LABEL may sneak out to some arbitrary LABEL.

And those evals, subroutine calls, and loops may nest in any order.
There's no one obvious outer context, like there's an obvious enclosing
block.


Eirik