From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sat, 31 Dec 2005 01:17:39 +0100
On Dec 30, 2005, at 17:50, Bob Rogers wrote:
> The attached patch is functionally complete, but I still have a few
> loose ends to nail down, so I thought it would be a good time to post
> it
> for review. The issues are as follows:
>
> 1. It needs more higher-level documentation. Is compiler_faq.pod
> the best place for this?
>
> 2. Binding 'foo' to a null PMC should cause find_global to err out
> with "Global "foo" not found", but this is not happening.
>
> 3. There are no tests for threads or stack-unwinding continuations.
> (Yes, I am procrastinating.)
I think I've missed to answer the last one WRT that - sorry. Anyway,
here are some comments:
No prob; thanks for your review.
- the patch looks really great and seems to cover all aspects to get
this running (just a minor nitpick: src/register.c:init_context() is a
common place to copy inherited context items)
Yes, thank you; that does seem to be the logical place. I think I had
passed this over because of the init_context call at src/register.c:325
(as patched) which doesn't pass the caller's context. But this
particular call looks like bit rot; it's only enabled if CHUNKED_CTX_MEM
is true. Should I flush it?
- the patch seems to miss the 'other part' of 'local' i.e. restoring
the old contents of a variable . . .
It never actually has to restore anything, because the old contents are
still in the appropriate stash. The new dynamic bindings shadow the old
one(s), and are undone simply by virtue of returning from the sub. This
is why the coroutine test case works the way it does. (FWIW, the
implementation uses what we old Lispers call "deep binding," mixed with
"shallow binding" (checking the stash) if a dynamic binding is not
found.)
. . . like e.g. described in 'perldoc perlsub' - (whatever the reason
is that it's doced there ;)
At a guess, I'd say that's the bucket into which all discussion of
scoping has been tossed.
- that is, Perl5 'local' is much more related to Perl6 'let' or 'temp',
it's not just hiding a variable, it looks to me much more like undoing
temporary damage, which looks to me like STM (w/o the needed
synchronization bits)
Actually, if I understand STM correctly, the dynamic_bindings stack
functions very much like a "memory log", except that it only applies to
find_global and store_global, which makes it cheaper. But you're right;
this is only part of what "local" can do.
- if the intent is just to temporarly hide a name, then it should be ok
(but not refer to 'local' at all)
I think it needs more thoughts and more (common) infrastructure .
leo
Hmmm [he mumbles as he studies "perldoc perlsub", for the first time in
ages . . . ]
It's true, this patch doesn't address dynamic binding of Perl5
typeglobs and arbitrary references (i.e. "local $SIG{INT} = ..."). But
it does implement all of the rest of the functionality of Perl5 "local",
it seems to me. So, if you prefer, one could just call it "dynamic
variable binding" instead of the more general "dynamic binding."
In any case, I agree that it needs more thought. Here's a sampling
off the top of my head:
1. Dynamic binding of typeglobs. I haven't noticed a Parrot concept
of "symbol table entry"; in particular, Matt's namespace proposal
<http://xrl.us/i5n6> doesn't mention one. Consequently, I am assuming
that each Per[56] typed variable is named with its sigil and treated
separately for purposes of *_global operations. Therefore, it should be
both necessary and sufficient for "local *foo = ..." to expand into code
that binds each sigil separately. True? How else could you do it?
2. Dynamic binding of hash and array elements. The "perlsub"
example of this (the paragraph starts with "It's also worth taking a
moment to explain what happens ...") pretty much requires that this be
done via "temporary damage" (aka shallow binding) -- I can't think of
any other way to mutate $ary[5] and then restore @ary as described.
This has the drawbacks cited in the "Dynamic binding" proposal I posted
last Friday, but that's just too bad, as there isn't a choice.
Consequently, I would argue that these require a separate mechanism.
Now, if you buy both of these arguments, then that suggests I should
finish the patch as designed, and design the rest of "local" support
separately. If not, though, I may not have time to finish a more
general design during my window of opportunity, in which case finishing
the patch as designed may still be a good strategy.
But I will go back to the drawing board, and post more later . . .
-- Bob
