Bob Rogers wrote:
- Overall, I want the implementation of dynamic binding to be tied in
more closely with the implementation of globals and lexicals.
Particularly lexicals. They're already operating under the same scope
constraints as locals. They already have storage for named variables
relevant to a particular scope, and the mechanism for handling scopes
within scopes.
I'm afraid I don't follow you, particularly the "operating under the
same scope constraints" part. It seems to me that lexical variables are
orthogonal to dynamic/global variables, and dynamic binding is purely a
feature of globals. And lexicals are necessarily simpler, because all
possible references are available to the compiler. So nested scopes are
handled by the compiler simply by using a different register. Globals
and dynamic bindings, because they must be visible to code in multiple
compilation units, must necessarily use different mechanisms.
The proposal starts off talking about Perl 5's 'local' and Perl 6's
'temp'. They are lexical in nature (though they're more feature-rich
than simple lexicals). They only exist within a specific lexical scope,
and "roll back" on exiting that scope.
Why would dynamic binding only apply to globals? Perl 5's 'local'
doesn't apply to lexicals, but Perl 6's 'temp' will.
- I like the idea of "thread locals": global variables shared across
threads, but with a local value in one particular thread. I'll have to
mull that one over some more. It seems fundamentally different from
"scope locals", to the point of deserving a different way of interacting
with the feature (perhaps more closely tied to the concurrency model
than to variable storage).
By "local value" I assume you mean "local binding," which (in the
version I posted) would indeed be per-thread. But in what sense are
"global variables shared across threads"? Without the binding, all you
have is the name, which isn't terribly variable.
>
And "scope locals" -- aren't all variables local to their scope by
definition, even if that scope happens to be universal?
So I'm pretty sure I must be misunderstanding something . . .
Your proposal mixes two ideas. One is the idea of 'local'/'temp', the
other is thread-level dynamic bindings. (I called these two concepts
"scope locals" and "thread locals", but "scoped locals" is probably a
better term for the first set.)
A more explicit phrasing of my comment about "local value" is: "In the
case of a global variable shared across threads, this proposal would
make it possible to have a version of the variable local to one specific
thread, so changes to that variable within that thread do not affect the
variable's value in the other threads." I consider this to be the most
interesting idea put forth in the proposal.
While I'm not accepting the currently proposed implementation, this idea
is likely to make it in. Possibly as a lightweight use of STM, possibly
as part of the new concurrency model(s), or possibly as a variation on
scoped locals.
- We keep adding hacks to get around the fact that Parrot doesn't
handle scopes smaller than a compilation unit particularly well. If we
tackled that quirk, dynamic binding would likely fall out more
naturally, not to mention exception handlers, lexical variables, etc.
I'm afraid I don't follow this, either. "Scope" is mostly an HLL
concept; what would Parrot need to do to support them better? Or are
you talking about debugger annotation for variable lifetime?
It's true that scope is an HLL concept, but the whole idea of Parrot is
to provide tools for implementing HLLs. Parrot's concept of scope is
still quite primitive, and not very helpful to compiler writers.
Allison
