At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
[stuff I snipped]
>I'm worried a little about building features with global effects.
>Part of Perl 6 is elimination of action-at-a-distance, but now
>we're building the swiss-army-knife-of-action-at-a-distance.
I don't know how much of a stated design goal this is. Most of the globals
that are getting eliminated are mostly because of coarseness issues. ($/, say)
>What worries me the most is that allowing %MY to change at run-time
>slows down code that doesn't do it. Maybe we can figure out how
>to reduce the impact, but that's time IMHO better spent making
>existing code run faster.
Maybe, but... with this sort of thing, if we know about it before we code,
we're fine. It's one of the things worth spending some design time on. Even
if we ultimately don't do it, I think it'll be time well spent. (There have
been a number of features that have been discussed that ultimately were
discarded, but thinking about them expanded the interpreter's design in
pleasant ways)
>You wrote on perl6-internals:
>
> get_lex P1, $x # Find $x
> get_type I0, P1 # Get $x's type
>
> [ loop using P1 and I0 ]
>
>That code isn't safe! If %MY is changed at run-time, the
>type and location of $x will change. You really need to put
>the code for finding $x *inside the loop*.
Only if $x is active. (i.e. tied) In that case we need to do some other
things as well. I was assuming the passive case, for which the code was
valid since there wasn't any way for it to be changed.
>Maybe we can detect a few cases when it's safe to move
>get_lex out of a loop, but if the loop calls any subs or
>non-core ops we're stuck.
Maybe. I think we're going to end up assuming ops have no side effects
unless explicitly noted to have some, and those rules will be given to the
compiler. As for subs, we do have to worry some, but we are in the nice
position of being able to know if a sub does or doesn't change things
globally. We're certainly not limited to keeping C's pathetic "just
parameters" as the only metadata stored about functions. We can have "uses
string eval", "uses MY", "OK but calls x, y, and Z", or whatever stored for
each sub so we can have an idea of what alters things.
Now, granted, it might be such that a single "uses string eval" or "uses
MY" in the program shuts down optimization the same way that $& kills RE
performance in perl 5, but we are in the position of tracking that.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
