Em Ter, 2010-05-18 às 15:15 +0100, nigelsande...@btconnect.com escreveu:
> > 1) the interpreter doesn't need to detect the closed over variables, so
> > even string eval'ed access to such variables would work (which is, imho,
> > a good thing)
> You'd have to explain further for me to understand why it is necessary to
> keep whole scopes around:
> - in order to make closures accessible from string-eval;
> - and why that is desirable?
I have no strong opinion on that, actually... Pointing to the outer
scope was simply an easy way to have it working...
But this is currently, iirc, a requirement for the language, and
supported by rakudo and pugs...
<ruoso> perl6: my $a; { my $b = 1; $a = sub { return eval '$b++' } };
say $a.(); say $a.(); say $a.();
<p6eval> ..pugs, rakudo 689429: OUTPUT«123»
> > 2) all the values in that lexical scope are also preserved with the
> > closure, even if they won't be used (which is a bad thing).
> Please no! :)
> This is essentially the biggest problem with the Perl 5 iThreads
> implementation. It is the *need* (though I have serious doubts that it is
> actually a need even for Perl 5), to CLONE entire scope stacks every time
> you spawn a thread that makes them costly to use.
hmmm... I wasn't expecting to clone the entire scope stack, but rather
to ask the owner of the outer scope for a value...
But I have to admit that importing the symbols used from outer scopes to
the current scope and making them shared (or a RemoteValue in my
original idea) is probably prettier. Accessing the OUTER scope in
run-time (via string eval, OUTER::{$var} or CALLER::{$var}) could be
subject to additional restrictions.
daniel
