On 8/4/2011 1:35 PM, David Barbour wrote:
On Thu, Aug 4, 2011 at 12:43 PM, BGB <[email protected]
<mailto:[email protected]>> 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
[email protected]
http://vpri.org/mailman/listinfo/fonc
