in reply to Are common access expressions optimized?

To optimize that would involve more code than you might think--once the exist test was done, the code would need to check on the status of $very{nested}, $very{nested}{hash}, and $$very{nested}{hash} as any part of that expression could be tied or otherwise magic. That makes this rather more interesting to optimize.

Replies are listed 'Best First'.
Re: Re: Are common access expressions optimized?
by John M. Dlugosz (Monsignor) on Dec 24, 2002 at 03:04 UTC
    Unless the compile-time attributes say that there's nothing funny about it, that even if tied everything leading up to the last deref is "pure" or idempotent.

    I see the opcode structure on the Parrot takes multiple keys directly. Does that help matters?

    So, simply by using a temporary (either named or topicalized), I'm saying explicitly that the subexpression is only to be evaluated once.

    In Perl 6 there is the // or err operator that will take care of some of this, but no native way to handle exists though maybe undef.

      Unless the compile-time attributes say that there's nothing funny about it, that even if tied everything leading up to the last deref is "pure" or idempotent.
      Yep. If you tell us it's OK, we can do it. Whether we will or not is an open question--writing optimzers isn't easy, and it'll likely be a while before parrot gets one anywhere near as good as, say, DEC^WCompaq^WHP's or IBM's C compiler.
      I see the opcode structure on the Parrot takes multiple keys directly. Does that help matters?
      Nah. Makes it even worse. The reason for the multidimensional key structure is so that a tied variable could potentially consume multiple keys at once, as it knows you're looking for a two or three or four level deep thing, so there's even less information (potentially) on how things work. :)