This Week on Perl 6 (19 - 25 August 2001)
Notes
This Week in Perl 6 News • Closures |
You can subscribe to an email version of this summary by sending an empty message to perl6-digest-subscribe@netthink.co.uk.
Please send corrections and additions to bwarnock@capita.com.
Another quiet week, with only 52 messages. 22 authors contributed to 10 threads.
Closures
(17 posts) Dave Mitchell started the debate on whether closures should be explicitly declared, by way of having lexical variables not import into nested blocks implicitly. Some areas of discussion centered around whether named subs are closures, closures are ever created accidentally, and the current behavior is correct.
Dave further provided some insight into how closures actually work, to help explain his point:
With the $x:
foo() is a closure created at compile time. By the time the main {} block has been executed (but before foo() is called), the $outer:x is undef, and $foo:x is ‘bar’ (standard closure stuff). When foo() is executed, the anon sub is cloned, and at that time, $anon:x is set from from foo’s pad, so it gets ‘bar’.
Without the $x:
foo is no longer a closure - ie it doesnt have a private copy of $x in its pad. At cloning time, sub {$x} picks up its value of $x from $outer:x, since there isn’t a $x in foo’s pad - thus it picks up ‘undef’ from $outer:x that went out of scope a while ago.
Method Signatures
(12 posts) Damian Conway answered last week’s question on whether subroutine signatures will apply to methods in Perl 6. There was some subsequent debate on how strict Perl’s optional typing would need to be, and how easily it would still be to circumvent through regular Perl magic.
Foo::$bar
(2 posts) Brent Dax asked:
I was thinking about Perl 6 today, and thought of something: if the sigil is now part of a variable’s name, does that mean that $Foo::bar should actually be Foo::$bar in Perl 6?
Michael Schwern’s thinkingwas:
Techincally ‘bar’ is shorthand for the complete name, ‘Foo::bar’. So ‘$Foo::bar’ would remain.
Besides, Foo::$bar looks funny.
Perl 6 Internals (Yes, There Are Some…)
(5 posts) Dan Sugalski announced that he’s got code:
I’ve got the rudiments of the parrot interpreter and assembler built and running. (I get around 23M ops/sec on a 700MHz Alpha EV6) I’m beating it up enough to get it into a reasonably released state, so while I’m doing that…
Simon Cozens made this suggestion:
On an unrelated note, and seeing Dan [and] Bryan’s experiments with different kinds of switch/dispatch, I think it makes sense to separate out ops which correspond to PMC vtable functions (add, subtract, etc.) and those which don’t. Those which do can be done with a switch to save a function call, and those which don’t can use function pointers. This achieves the same objective as auto-generating op wrappers around vtable functions, (saving one level of indirection) while leveraging the gain from a split-level op despatch loop.
More Modules
(7 posts) John Siracusa continued the discussion on the Perl 6 module plan, calling for more conformity in APIs, and deepening the namespace heirarchy.
Kirrily Robert pointed to some work she’s been doing on the perl5-porters list - perlmodstyle - in preparation for Perl 6.
Last Words
We should be seeing Apocalypse 3 (Larry Wall) and Exegesis 3 (Damian Conway) sometime this week, if things are on schedule. Nathan Torkington is currently evaluatingSourceForge as the Perl 6 code repository.
I’d like to keep the code on Sourceforge from the get-go. I don’t have much experience with Sourceforge, though, and would like to talk to someone who has. Which bits work well? Which bits aren’t worth the effort? Any tips or tricks to pass on?
If you’ve got some opinions, pass them on to Nat.
Tags
Feedback
Something wrong with this article? Help us out by opening an issue or pull request on GitHub