(This post isn't very punny. For those of you who need puns to survive, try to figure out why jnthn++ named the IRC logs "the hottest footwear" recently. The answer, as with all good puns, is highly unsatisfying.)
My quest for a Perl 6 implementation takes me ever deeper into the esoterics of lexpads, runtimes, and a far-more-than-everything-you-needed-to-know mindset. Today some random firings in my brain turned into the following conversation on #perl6.
During the conversation, I proposed two theories, both of which turned out to be wrong. (pmichaud++ shone the necessary light both times.) Being wrong felt less important than getting my mental model fixed.
I first thought of presenting the results of the below conversation as a simple tutorial ("How our declarations work. The complete guide."), but now I think that the conversation, minimally edited, manages to be such a tutorial on its own.
Besides, blogging things in their raw and undigested form is a sign of the times. Enjoy!
<masak> I have a question. is there a need for a special "package lexpad" containing 'our'-declared variables, or can the package lexpad simply be equated to the topmost lexpad in the package?
<masak> my suspicion is the latter, but I might be missing something.
<pmichaud> the package lexpad can't be the same as the top most lexical
<pmichaud> module XYZ { my sub abc() { ... } }; # abc should not appear in the package
<masak> oh!
<masak> right.
<masak> so, separate one, then.
<jnthn> Additionally, lexpads are meant to be static by the time we hit runtime, and you're allowed to shove stuff into the package dynamically. Not quite sure how those two hold together.
<pmichaud> well, module XYZ { ... } creates a lexical XYZ entry that holds the package entries
<jnthn> Aha!
<pmichaud> and it's just a hash, really.
<masak> does inserting the package lexpad below the outside lexpad (and above the topmost lexpad) make sense? that way, Yapsi wouldn't need any special opcodes for doing 'our'-variable lookups.
<pmichaud> the package lexpad is an entry in the outside lexpad, yes.
<pmichaud> I'm not sure it encapsulates the nested lexpad, though.
<masak> hm.
<masak> if it doesn't, I don't really see how it's visible from inside the package.
<masak> I've more or less convinced myself that sandwiching it between outer and topmost is what I want to do for Yapsi.
<pmichaud> our &xyz can make an entry in both the package and in the lexical.
<pmichaud> this is what rakudo does now.
<pmichaud> we have to do similar things for methods already, too.
<masak> sure. it makes entries in both.
<pmichaud> by having entries in both, that's how it's visible inside the package
<masak> hm, indeed.
<masak> no need to have the package lexpad visible from inside.
<pmichaud> anyway, sandwiching might work too. haven't quite gotten to that point in Rakudo thinking yet. And it can get a bit tricky with multis.
<masak> no need to sandwich it in, either. it can sit in limbo outside the tree of scopes.
<pmichaud> oh, I know why it perhaps shouldn't (or should) be visible:
<pmichaud> my $x = 'lexical'; module XYZ { say $x; { our $x = 'package'; } }
<masak> ...yes?
<pmichaud> I'm pretty sure "say $x" needs to grab the 'lexical' $x, not the one that might be "sandwiched" in a package.
<masak> of course.
<masak> that falls out from ordinary scope nesting and shadowing.
<masak> innermost block binds its lexical to the container in the package lexpad.
<masak> so, that speaks out against sandwiching.
<masak> pmichaud++
So there you go. There's a separate package scope, and it isn't sandwiched.
(Answer: The missing link is the "IR clogs" meme from #parrot. I can hear you groaning... I did warn you.)
try to figure out why jnthn++ named the IRC logs “the hottest footwear” recently
IRC logs → I.R. Clogs → infra-red clogs?
Re:Let me guess…
Aristotle on 2010-09-03T14:17:09
Ah d’uh, you gave the solution at the end. Pfff.
