Re: Thread Clarification (Re: [fonc] Physics and Types)
On Thu, Aug 4, 2011 at 12:10 AM, BGB 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. 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). 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. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Thread Clarification (Re: [fonc] Physics and Types)
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
Re: Thread Clarification (Re: [fonc] Physics and Types)
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
Re: Thread Clarification (Re: [fonc] Physics and Types)
On Thu, Aug 4, 2011 at 12:43 PM, BGB cr88...@gmail.com wrote:
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.
I'm not suggesting you make a special exception at 'async {}'. I'm
suggesting you fix the semantics of your dynamic variables so that you don't
need a special exception. The *behavior* of your dynamic variables is the
problem.
You might need to give up some of your preconceptions about what a dynamic
variable 'is' in order to develop a semantics that works well with
concurrency. I have made suggestions already, but you were not open to hear
them.
then I would have essentially 7 different types of variables...
And now you have 6 problems...
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).
Application scripting benefits a lot from security. For example, if I have a
secure scripting language, I'm far more free to utilize applications,
extensions, mashups, libraries, and modules that I do not trust. Even
JavaScript was developed with security in mind, though it did a shoddy job
of it (thus the single origin restriction).
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: Thread Clarification (Re: [fonc] Physics and Types)
On 8/4/2011 1:35 PM, David Barbour wrote:
On Thu, Aug 4, 2011 at 12:43 PM, BGB cr88...@gmail.com
mailto:cr88...@gmail.com wrote:
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.
I'm not suggesting you make a special exception at 'async {}'. I'm
suggesting you fix the semantics of your dynamic variables so that you
don't need a special exception. The /behavior/ of your dynamic
variables is the problem.
You might need to give up some of your preconceptions about what a
dynamic variable 'is' in order to develop a semantics that works well
with concurrency. I have made suggestions already, but you were not
open to hear them.
these either amounted to special cases or fundamental design changes.
one can't really freely make fundamental alterations to the semantics of
a language already in use without creating some problems.
this is about like going and claiming that copying closures across a
network socket (say, to a different computer/node) should give each a
local copy of their lexical environment, rather than having a
shared/synchronized lexical environment.
in a few cases, this would make sense, but is not the semantics most
people would likely expect if they send a closure over a socket (likely,
they would expect it to behave just the same as if it were still on the
originating system WRT the lexical scope).
likewise, unless stated otherwise, the expected semantics would be for
environments to be preserved across thread-creation boundaries unless
there is a well defined reason for it to be otherwise.
then I would have essentially 7 different types of variables...
And now you have 6 problems...
most are related to various cases for how variable scoping and lookup
are implemented.
when one has a language which basically implements a common superset of
ES-like, C-like, and Java-like semantics, there are likely to be a few
edge cases (if one wants edge-cases... they can look into the
type-system...).
actually, closer to the core, the semantics are much closer to an old
Scheme variant of mine (2000-2003 or so), which had basically partially
fused together Scheme and Self (the core language was derived from
Scheme, but I had used a Self-like object system).
the BGBScript VM is largely layers of cruft and sugar on top of this
(especially 2006 onwards).
a lot of the core machinery though goes back for around 10 years now,
despite the levels of hacking/expansion/... over the years.
the original Scheme variant had 4 types of variable:
lexical variables (Scheme proper);
dynamic variables (inherited from Common Lisp);
object variables (from Self);
object-delegate variables (from Self).
the additions since then have been:
toplevel (when the toplevel became its own scope a few years back,
splitting it off from object);
package (when packages were added).
thread-local would make it 7.
actually, there are 2 additional sub-types:
lexical-delegate variables (used to implement import and similar);
dynamic-delegate variables (delegation via the dynamic scope).
if the above are included, this would mean 9 variable types.
however, I generally lump object/lexical/dynamic delegate variables all
under the category of delegate scope, hence why I say 7 rather than 9.
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).
Application scripting benefits a lot from security. For example, if I
have a secure scripting language, I'm far more free to utilize
applications, extensions, mashups, libraries, and modules that I do
not trust. Even JavaScript was developed with security in mind, though
it did a shoddy job of it (thus the single origin restriction).
it is usually assumed that when people uses mods, there is a certain
level of trust going on, much like installing any code on a local
computer.
similarly, most trust for an applications scripts comes from the
person who writes the application and its scripts, since presumably,
they will trust their own code (a programmer will not likely just
unintentionally type out exploits or a virus...).
hence, most non-trusted code would likely come either from 3rd parties
or from the internet.
granted, I have idly thought about security, but this hasn't really been
a huge priority for the nature and design of the language.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Physics and Types
On 08/03/2011 08:10 PM, Simon Forman wrote: On the other hand, there's a story (I believe it's in one of the VPRI documents but I couldn't locate it just now) about children using their machines to take pictures of a falling object and then analyzing the pictures and deducing for themselves the constant-acceleration rule for gravity. IIRC, this is one of the things on the Squeakers DVD. http://squeakland.org/resources/audioVisual/#cat547 Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Physics and Types
Oh awesome! Thank you both. That's got to be one of the single most profound uses of computers I've ever run across. Warm regards, ~Simon On Thu, Aug 4, 2011 at 6:19 PM, Alan Kay alan.n...@yahoo.com wrote: Here's the link to the paper http://www.vpri.org/pdf/rn2005001_learning.pdf Cheers, Alan From: Martin McClure martin.mccl...@vmware.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thursday, August 4, 2011 3:46 PM Subject: Re: [fonc] Physics and Types On 08/03/2011 08:10 PM, Simon Forman wrote: On the other hand, there's a story (I believe it's in one of the VPRI documents but I couldn't locate it just now) about children using their machines to take pictures of a falling object and then analyzing the pictures and deducing for themselves the constant-acceleration rule for gravity. IIRC, this is one of the things on the Squeakers DVD. http://squeakland.org/resources/audioVisual/#cat547 Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- I live on a Pony Farm: http://fertilefuture.blogspot.com/ My blog: http://firequery.blogspot.com/ The history of mankind for the last four centuries is rather like that of an imprisoned sleeper, stirring clumsily and uneasily while the prison that restrains and shelters him catches fire, not waking but incorporating the crackling and warmth of the fire with ancient and incongruous dreams, than like that of a man consciously awake to danger and opportunity. --H. P. Wells, A Short History of the World ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
