"Bryan C. Warnock" wrote:
> Generically speaking, modules aren't going to be running amok and making a
> mess of your current lexical scope - they'll be introducing, possibily
> repointing, and then possibly deleting specific symbols
How much do you want to pay for this feature? 10% slower code? 50%
slower? Do you want the feature at any price?
I don't like run-time frobbing of the symbol table. Not even
precise tweaking. ;) I think it's in bad style and inconsistent with
the purpose of lexicals. *But* bad style isn't a good argument
and I wouldn't be pursuing this if it were just a style issue.
The trouble lies in running the code. Lexicals used to be known at
compile time. Now they can change practically anywhere. It's like
using C and having *everything* be volatile. Except worse because
you don't even know the address where something is going to be.
A simple solution would be to allow lexical scope editing at
compile time, but not run-time. Change a BEGIN block's caller() so
that it is the scope being compiled instead of main. This achieves
the majority of the benefits (lexical imports at compile time)
without any downside.
There are two other things that are easy to add. If the
compiler knew in advance which lexicals might dynamically change,
it could generate better code and not slow everything down. A
trait called ":volatile" or something. IMHO this would also
show intent to the people reading the code that something funny
might happen to the variable. (Macros or compile-time injected
lexicals could declare the :volatile trait, so I would imagine
that some pretty interesting packages could still be written.)
The other thing is to permit attaching attributes to a
lexical scope. This allows undetected channels of communication
between callees. There are interesting things that could be
used for (carrying state between function calls in the same
scope or simple thread-local storage). And It wouldn't impact
compiled code at all.
- Ken
