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