At 12:34 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
>...
># new P0, list # New list in P0
># get_lex P1, $x # Find $x
># get_type I0, P1 # Get $x's type
># set_i I1, 1 # Set our loop var
># $10: new P2, I0 # Get a temp of the same type as $x
># add P2, P1, I1 # Add counter to $x, store
># result in P2
># push P0, P2 # Push it into the list
># eq I1, 65, $20, $10 # If loop counter's 65 goto
># $20, else $10
># $20 call foo # Call the sub
>...
>
>Are you expecting the optimizer to be *that* powerful?
Well, yeah. Why wouldn't it be? The code to be compiled isn't at all
tricky, and neither is it at all likely to be unusual for what we see in
perl. (Granted, I'd have written the function parameters to be
"$x+1..$x+65" in which case we'd have just created an iterator instead of
flattening things out) The translation was very straightforward, though I
could see having 65 separate creations (if we weren't sure we really did go
from 1 to 65) or creating a list from 1 to 65 at compile time and doing an
add of $x to it in list context, or creating a list of 65 $x and the 65
integers and adding the two lists together.
Which pattern the compiler took would probably be an interesting thing to
consider.
>If so, I think I'll stay with the execution engine... :^)
Works--we can use all the execution people we can get our hands on.
(Compiler people too, but I know that there are fewer compiler folks around)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
