On Friday 07 September 2001 12:56 am, Ken Fox wrote:
> "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?
Which feature? The introduction of new lexicals solely at compile time? We
can do that now.
I've already demonstrated that this is a solvable problem. Although,
admittedly, I wouldn't suggest actually *implementing* my solution,
I'm sure someone far more clever than I can come up with a viable one.
>
> 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.
But it clears up a *lot* of problems that were introduced with local.
Much like perlfunc says...
You really probably want to be using "my" instead,
because "local" isn't what most people think of as
"local". See the Private Variables via my() entry
in the perlsub manpage for details.
Lexicals were never about speed, they were about containership. A lot of
Perl's magic and power, however, only work when centered around globals and
locals. Muckings there, however, cause true "action at a distance" - what I
change here for my benefit may screw something up way over there that I
can't see. Allowing this to take place with lexicals reduces those risk
factors - do your magic here and only here.
>
> 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.
Lexicals being known at compile-time was a side-effect of the containership.
Yes, we want lexicals to be fast. Containing behavior lexically is slightly
more important, IMO. If it runs dog-slow, we won't do it. If it runs just
a tad slower, we probably should.
>
> 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.
Nope. Think 'require'.
>
> 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.)
Except that magic will probably be going on behind the scenes, so you don't
know it's magically. Otherwise, you'd just assign whatever it was to the
lexical variable and be done with it....
--
Bryan C. Warnock
[EMAIL PROTECTED]
