From: Allison Randal <[EMAIL PROTECTED]>
Date: Fri, 02 Nov 2007 15:24:40 -0400
Bob Rogers wrote:
>From re-reviewing our earlier correspondence, I get the impression
> that you have a particular implementation in mind, one which doesn't
> seem to work for my use case. Perhap
Bob Rogers wrote:
From re-reviewing our earlier correspondence, I get the impression
that you have a particular implementation in mind, one which doesn't
seem to work for my use case. Perhaps you should describe the use case
for your implementation, and then we can decide whether to combine
w would Parrot figure out which
bindings need attention, and what values to restore?
From re-reviewing our earlier correspondence, I get the impression
that you have a particular implementation in mind, one which doesn't
seem to work for my use case. Perhaps you should describe the use case
for your implementation, and
Bob Rogers wrote:
All I am talking about is the equivalent of what "local $var" provides
for Perl 5, i.e. dynamically-scoped binding of scalar "package
variables."
Perl 5 locals and Perl 6 temps are quite different than Lisp special
variables. I don't immediately see a way to explain this any
From: Allison Randal <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 19:16:37 -0700
Bob Rogers wrote:
>In what seems to have become an autumn tradition in the Parrot
> community, I am about to make my third annual attempt to implement
> Parrot support for what Common Lisp calls "s
If the problem is simply "implement Common Lisp special variables", then
the most likely solution is to create a LispSpecialVar PMC. In the same
way that a MultiSub acts like a sub but internally stores a list of
subs, the LispSpecialVar would act like an ordinary variable to Parrot
internals a
Bob Rogers wrote:
In what seems to have become an autumn tradition in the Parrot
community, I am about to make my third annual attempt to implement
Parrot support for what Common Lisp calls "special variable binding."
[...]
FWIW, I am (re-)starting this project a few weeks earlier than I
scoping" [1]; after last fall's email discussion [2], I am hoping that
"dynamic variable scoping" will capture the, ah, scope of this
particular project in a way that is satisfactory to everyone.
In the aforementioned thread [2], we seem to have reached a number of
conclusions
