On 8/4/2011 1:06 AM, David Barbour wrote:
On Thu, Aug 4, 2011 at 12:10 AM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> wrote:
The new thread should inherit the entire dynamic scope -
logically, a local copy thereof. If there are object
references mixed in, then the new thread now has a copy of
these references, but the reference variables initially point
to shared objects.
they would inherit the entire dynamic scope directly, but the
issue would be that dynamic variables which were not re-declared
would likely be shared with the parent (and so couldn't be
modified without effecting the parent).
I had used 'copy on write' in a sort of continuation passing style.
Performance did not suffer.
it is not about performance, it is about what happens when one assigns
the variable.
if the parent thread sees its "thread-local" variable change when a
child-thread assigns to it, this is a problem. it is a natural result
though of the basic semantics.
dynamic scope has a lower priority than lexical scope though (and
a lower priority than object/class scope), so if any lexically
visible bindings exist, they will be bound against first.
technically, dynamic scope is just just prior to doing a full
brute-force search (following delegation chains, tracing through
packages, seeing if the C FFI knows about it, ...).
I would prefer dynamic scope to be explicit. Lisp tagged special vars
with a '*' - e.g. you could ask for something like '*x' to get the
dynamically scoped x. I had used a keyword to extract the full record
of dynamic variables (to support various security idioms).
AFAIK, the '*' was just a naming convention (much like macros in C being
all caps), and it was the "defvar" that made it dynamic.
in my case, it is explicit, via a modifier keyword when defining the
variable.
so:
var x; //lexical variable (except at toplevel or in a class)
dynamic var y; //dynamic variable
Your idea of searching for variables in non-local scopes sounds
horribly broken. Dynamic scope and objects can replace use of globals
and control access to FFI. It is much easier to mock up a test
environment, or provide a sandbox, when you control the context.
the context is controlled, and via objects.
internally, however, most of this "global" context is built from linked
objects ("dictionaries") and delegate variables.
there is no "global toplevel" in the sense as it would be understood in
C, as the toplevel is an object.
so, a dictionary is naturally a key/value mapping:
obj.key => value
now, add to this "delegates", where delegates are special key/value
pairs which, rather than simply naming an object, delegate any unknown
accesses to it.
then, consider the FFI/... is itself exposed to the VM as an object, and
is known about because it is delegated to (say, by the special "top"
object).
the "search" is then basically a graph-driven search over the objects
reachable via delegation chains.
note that, for example, if you spawned some code with an empty object in
place of "top", then it wouldn't see anything:
the FFI wouldn't work;
"import" wouldn't find any packages;
...
actually, if one types:
"top[#:ctop]=null;"
this would kill access to the FFI, rendering all C declarations as
no-longer visible.
syntax note: #name is a symbol, and #:name is a keyword. symbols (and
strings) access ordinary slots, whereas keywords access delegates.
less destructive would be this:
top=top.clone(); //set toplevel to a clone of the toplevel
top[#:ctop]=null; //kill ctop (FFI) in current toplevel
now, say:
top[#:bsvm]=null; //will also kill the ability to import packages...
top={}; //this will kill off the ability to do much of anything.
say:
async {
top={};
//now we have a thread with no more toplevel scope (no FFI, and no
visible packages)
...
}
granted, yes, a lot of this is stuff that code should ideally not be
messing with directly.
also, assigning delegates like this will cause the lookup hash to be
flushed...
technically, things get a little more weird when class/instance objects
get involved.
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
