On 8/4/2011 7:55 AM, David Barbour wrote:
On Thu, Aug 4, 2011 at 1:53 AM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> wrote:
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.
If a problem is a natural result of /your/ language's semantics, then
fix your language semantics. ;-)
it is a straightforward interpretation of scope:
both lexical and dynamic scope cross code boundaries with no effects on
their behavior.
this makes an issue for "async { ... }", as the scope is retained across
thread boundaries.
altering general semantics mostly to help in a special case is not ideal.
one possibility was to have an "async dynamic var" which would be either
cloned or dropped, but this is an added implementation hassle.
almost may as well just add dedicated TLS, since TLS vars at least have
the semantics one would expect from TLS vars: being globally assignable
and thread-local.
possible declaration syntax:
"static async var foo;"
then I would have essentially 7 different types of variables...
the context is controlled, and via objects.
if one types:
"top[#:ctop]=null;"
this would kill access to the FFI, rendering all C declarations as
no-longer visible.
That looks okay. Now, 'top' itself should be part of your dynamic
scope, and you'll be all set.
it is already a context-based pseudo-variable (along with 'this').
there are a few operations which change it implicitly (mostly, this can
be done with "load()" and "eval()").
like: "eval(myexpr, newtop)" or similar.
an interesting idea would be to go add a "withtop(obj) body" form, which
would execute body with the given object as its top-level.
originally, top was linked to by 'this', but this created other issues,
namely that one always needed to be in an object which delegated to the
toplevel. later I changed the semantics, putting the toplevel into
another pseudo-variable, sometimes creating confusion (in API calls,
...) as to whether 'this' or 'top' is in question (could clarify this
more in the APIs).
by default, most calls from C use the main/default toplevel, which gives
full access.
note: does not apply to calling closures, where closures capture their
toplevel (in addition to their lexical scope).
working with packages also creates a little bit of awkwardness with
user-defined toplevels, as this stuff builds on code (originally built
for a custom JVM implementation) which assumes a global toplevel and
package system, essentially requiring a globally unified package system
(despite packages being delegated to from the toplevel).
no ideal solution exists for the above.
but, anyways, this language wasn't originally designed to be a
high-security language or anything, but instead, to do high-level
application scripting (and for something often called "mods", which is
when one uses a package to override the default behavior of the program).
the reason then so much emphasis is given to having transparent
interfacing between BS and C is because BS is intended to be able to
have access to most aspects of the running program, ideally operating
with a similar level of power (over the application) to C itself
(meaning ability to readily muck with C code and data).
granted, yes, one wouldn't want untrusted code from the internet doing
this, but I am not exactly implementing a web-browser here either.
a partial past idea (WRT security) had been the idea of having invisible
security tokens and using ACLs or similar, but I never really bothered
with this thus far (and it could also impact performance some).
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
