Re: continuation taken?
On Thu, Jul 31, 2008 at 05:25:53AM -0500, John M. Dlugosz wrote: In S04, Note that temporizations that are undone upon scope exit must be prepared to be redone if a continuation within that scope is taken. What will create a continuation there and how do you take it? That is, how will this ever happen? At this point I'm not sure that temp variables are even going to make it into the final design. Context vars are much more well-behaved with respect to continuations and multithreading since they're always rooted in some lexical scope that is ancestral in your dynamic scope, and hence automatically managed by closure/continuation mechanisms. Alternately, temp may end up being a syntax for cloning an outer context var. Not sure how let would work in that scenario, unless a KEEP copies the final value outward. I guess that'd work. As for temporizing the results of code execution, that probably will have to wait on a coherent transactional memory model, which may or may not be deferred till after 6.0.0, but my bets are on may at this point. :) Larry
Re: Code-only forms?
On 2008 Aug 2, at 12:57, Larry Wall wrote: On Thu, Jul 31, 2008 at 05:56:14AM -0500, John M. Dlugosz wrote: In S04, Other similar Code-only forms ... What does that mean? It is feebly attempting to say that, because these are control flow functions, the argument is really a thunk that the function has control of when and how it's executed, much like in the constructs: $x thunk $x || thunk $x ?? thunk !! thunk Haskell demonstrates that this is simply lazy application. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Edits to submit
I've edited several of the S??.pod files,but I have not heard back from the owner ($Larry, whose name is on the top of the file) about accepting merging or rejecting my changes. I've posted the files to http://www.dlugosz.com/Perl6/offerings/ so they don't get lost, until someone with authority wants to diff them. --John
Re: Code-only forms?
OK I think I''m getting it. You seem to have introduced the ability to use a statement rather than a block in these constructs. E.g. try blahblah; Is that in general? So the statements needs to be closure-block-like, even though braces are not written, so anything that depends on it being an inner block is illegal. So if blahblah was a macro that wanted to, say, ïmport something into the current scope in the manner of a my declaration, it should be able to sense that its current context is not real but one of these thunks; depending on the nature of the macro it needs to know to navigate to the correct ::MY context or emit an error. Perhaps code in such a situation that accesses ::MY etc. should see it invisibly redirected to the proper lexical scope but readonly. The behavior needs to be well-specified so that code will mean the same thing if executed on an implementation that actually generated block-like thunks or one that used machine level goto instructions to jump around the conditional code without changing contexts. --John Larry Wall larry-at-wall.org |Perl 6| wrote: On Thu, Jul 31, 2008 at 05:56:14AM -0500, John M. Dlugosz wrote: In S04, Other similar Code-only forms ... What does that mean? It is feebly attempting to say that, because these are control flow functions, the argument is really a thunk that the function has control of when and how it's executed, much like in the constructs: $x thunk $x || thunk $x ?? thunk !! thunk It's also basically claiming that thunks have dynamic scope without lexical scope. That is, if you said my $x in such a thunk it would propagate to the lexical scope of the statement, but a temp would presumably not. But arguably the proper thing would be to outlaw lexically scoped declarations entirely in such a conditional thunk, akin to the P5.10 restriction on my $x = 1 if 0; Larry
