Re: The Block Returns
[EMAIL PROTECTED] (Austin Hastings) writes:
> Frankly, I think I'd rather see:
Some nits:
> macro atexit($code) is parsed(/{ * }/) {
Probably just
macro atexit($code) is parsed(//) {
> $block .= $code;
$block _= $code;
Dunno what .= would mean now . is method call. I'm sure someone will make it
mean something. :)
> eval($block) if defined $block;
I prefer $block.compile.run to eval()
--
The entirely inscrutable thing to me, looking back on myself, is my total want
of all reason, will or design in the business; I had neither the resolution to
win Adèle, the courage to do without her, the sense to consider what was at
last to come of it all, or the grace to think how disagreeable I was making
myself at the time to everybody about me. - John Ruskin.
Re: The Block Returns
Simon Cozens writes:
> [EMAIL PROTECTED] (Austin Hastings) writes:
> > Frankly, I think I'd rather see:
>
> Some nits:
>
> > macro atexit($code) is parsed(/{ * }/) {
>
> Probably just
>macro atexit($code) is parsed(//) {
>
> > $block .= $code;
> $block _= $code;
$block ~= $code;
Rather. :-)
> Dunno what .= would mean now . is method call. I'm sure someone will make it
> mean something. :)
>
> > eval($block) if defined $block;
>
> I prefer $block.compile.run to eval()
It'd might have to be, too, as $block isn't a string, it's a syntax tree
(but in string context, it might just turn into a decompiled -- or saved
-- form).
Luke
Re: The Block Returns
On Fri, 3 Oct 2003, Simon Cozens wrote: > [EMAIL PROTECTED] (Austin Hastings) writes: > > eval($block) if defined $block; > > I prefer $block.compile.run to eval() They're not quite equivalent -- I think eval's still wrapping a try/catch around the call. Dan
Re: The Block Returns
On Fri, 3 Oct 2003, Simon Cozens wrote: > Dunno what .= would mean now . is method call. I'm sure someone will make it > mean something. :) I've been saying for some time now that .= should mean exactly what one would expect it to mean, method call and assign the result, for code like $str .= lc; $linkedlist .= next; $structure .= clone(deep => 1); and such things. Really, making it mean anything else (including nothing at all) would be counterintuitive. -- Adam Lopresto http://cec.wustl.edu/~adam/ perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'
Re: The Block Returns
Austin Hastings wrote:
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 10:23 PM
To: Jeff Clites
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The Block Returns
Jeff Clites writes:
Speaking to the practical side, I have written code that has to
disentangle
itself from the failure of a complex startup sequence. I'd love to be
able
to build a dynamic exit sequence. (In fact, being able to do &block
.=
{ more_stuff(); }; is way up on my list...)
I've wanted to do that sort of thing before, but it seems simpler
(conceptually and practically) to build up an array of cleanup
subs/blocks to execute in sequence, rather than to have a .= for
blocks. (Another reason it's handy to keep them separate is in cases in
which each needs to return some information--maybe a status which
determines whether to proceed, etc.)
But this is already supported, in its most powerful form:
wrap &block: { call; other_stuff() }
Hmm, no.
That does a call, which presumes a return, which burns up who-knows-how-many mips. Given that the compiler is being forced to remember the code in case someone overloads the semicolon operator, or whatever, I don't think it's unreasonable to catenate the .source values of various blocks, and that seems a reasonable behavior for infix:.=(Block, Block) {...}.
Especially since the other way turns into:
macro atexit(Block $b) {
get_the_current_sub().eval("my &block = {};")
unless defined █
wrap &block: { call; $b(); };
}
Which makes two calls per additional whosit.
Frankly, I think I'd rather see:
macro atexit($code) is parsed(/{ * }/) {
get_the_current_sub().eval("my $block;")
unless defined $block;
$block .= $code;
}
macro return($retval) {
eval($block) if defined $block;
leave Routine, $retval;
}
But that imposes eval() pretty frequently. Better to provide some lower-level hackish way to agglutinate Blocks.
Isn't this one of the prime examples of why CPS is being use, it allows
for Tail Recursion Optimization. With TRO all your worries about
overhead do to the wrap go away.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: The Block Returns
On Thu, 2 Oct 2003, Mark A. Biggar wrote: > Austin Hastings wrote: > > But that imposes eval() pretty frequently. Better to provide > > some lower-level hackish way to agglutinate Blocks. > > > Isn't this one of the prime examples of why CPS is being use, it allows > for Tail Recursion Optimization. With TRO all your worries about > overhead do to the wrap go away. This isn't why CPS is being used under the hood. (Nothing in perl 6 propmted CPS) I wouldn't necessarily count on being able to do tail calls here either, as they potentially alter the semantics, or at least the introspectable environment, of the program as they make frames go away. Dan
Re: The Block Returns
Dan Sugalski <[EMAIL PROTECTED]> writes: > On Thu, 2 Oct 2003, Mark A. Biggar wrote: > >> Austin Hastings wrote: > >> > But that imposes eval() pretty frequently. Better to provide >> > some lower-level hackish way to agglutinate Blocks. >> >> >> Isn't this one of the prime examples of why CPS is being use, it allows >> for Tail Recursion Optimization. With TRO all your worries about >> overhead do to the wrap go away. > > This isn't why CPS is being used under the hood. (Nothing in perl 6 > propmted CPS) I wouldn't necessarily count on being able to do tail calls > here either, as they potentially alter the semantics, or at least the > introspectable environment, of the program as they make frames go away. I'm vaguely hoping that modules will be able to declare that they don't need to access a 'strict' caller and that they'll be happy with a return from caller that skips any tail calls. Then, if the Perl 6 compiler sees that all modules in play have declared themselves in this fashion it'll use optimized tail calls. However, thinking about that I'm not entirely sure how it could be done with a single pass compiler.
Re: The Block Returns
At 11:55 PM +0100 10/3/03, Piers Cawley wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: On Thu, 2 Oct 2003, Mark A. Biggar wrote: Austin Hastings wrote: > But that imposes eval() pretty frequently. Better to provide > some lower-level hackish way to agglutinate Blocks. Isn't this one of the prime examples of why CPS is being use, it allows for Tail Recursion Optimization. With TRO all your worries about overhead do to the wrap go away. This isn't why CPS is being used under the hood. (Nothing in perl 6 propmted CPS) I wouldn't necessarily count on being able to do tail calls here either, as they potentially alter the semantics, or at least the introspectable environment, of the program as they make frames go away. I'm vaguely hoping that modules will be able to declare that they don't need to access a 'strict' caller and that they'll be happy with a return from caller that skips any tail calls. Then, if the Perl 6 compiler sees that all modules in play have declared themselves in this fashion it'll use optimized tail calls. However, thinking about that I'm not entirely sure how it could be done with a single pass compiler. I think it's reasonable to allow you to mark your subs as being able to be tail-called out of. Subs with no lexical variables should be safe to call out of as well, though that's a bit dodgier. OTOH, it's not like too many folks walk up their call chain. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The Block Returns
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 11:55 PM +0100 10/3/03, Piers Cawley wrote: >>Dan Sugalski <[EMAIL PROTECTED]> writes: >> >>> On Thu, 2 Oct 2003, Mark A. Biggar wrote: >>> Austin Hastings wrote: >>> > But that imposes eval() pretty frequently. Better to provide > some lower-level hackish way to agglutinate Blocks. Isn't this one of the prime examples of why CPS is being use, it allows for Tail Recursion Optimization. With TRO all your worries about overhead do to the wrap go away. >>> >>> This isn't why CPS is being used under the hood. (Nothing in perl 6 >>> propmted CPS) I wouldn't necessarily count on being able to do tail calls >>> here either, as they potentially alter the semantics, or at least the >>> introspectable environment, of the program as they make frames go away. >> >>I'm vaguely hoping that modules will be able to declare that they >>don't need to access a 'strict' caller and that they'll be happy >>with a return from caller that skips any tail calls. Then, if the >>Perl 6 compiler sees that all modules in play have declared >>themselves in this fashion it'll use optimized tail calls. However, >>thinking about that I'm not entirely sure how it could be done with a >>single pass compiler. > > I think it's reasonable to allow you to mark your subs as being able > to be tail-called out of. Subs with no lexical variables should be > safe to call out of as well, though that's a bit dodgier. OTOH, it's > not like too many folks walk up their call chain. Actually, that makes a good deal more sense than my suggestion. As for hook functions, they probably want to hide themselves from C anyway, or hooking a single function in a call chain could cause introspective programs to fall over.
