At 03:02 PM 9/12/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > For something like:
> >
> >    @foo = @bar || @baz;
> >
> > I have no problem with the call sequence looking like (pseudo-codish here):
> >
> >     set_context(ARRAY, ASSIGN);
> >     foo->store(bar->log_or(bar, baz));
>
>But log_or must short circuit -- I think we have to preserve that behavior
>for all types or the (hypothetical future) optimizer might break things.
>It might translate "if" statements into ||, or vice versa. It might do dead
>code elimination. It might do liveness analysis.

It might make demons fly out your nose if you do something with undefined 
behaviours. :)

Seriously, even if we don't provide code to do what I'd like to with 
logical ops on aggregate data, I think we should still use this way to do 
things. That way it leaves it up to the left-hand element to determine it's 
truth or falsehood without having to actually return a false value.

It's possible, for example, for a tied/overloaded/really-darned-strange 
variable to look true but still be false. If you do:

   $foo = $bar || $baz;

and both $bar and $baz are objects, the 'naive' way is to make $foo be 
$bar. But it's distinctly possible that $bar really should be treated as a 
false value and $baz be used instead. Why? Dunno. Serious hand-waving here. 
(And yes, I know that's a danger sign... :) But I don't see any reason to 
preclude the possibility.

The optimizer's going to have to know the difference between active data 
(which is to say, things with code tied to them) and passive data (like 
'normal' perl data elements) and be more conservative with optimizations on 
active data. Heck, even if we have:

   my GigerInterface $clicks = 0;
   $count = $clicks || $last_clicks;

the optimizer can't assume that it boils down to:

   my GigerInterface $clicks = 0;
   $count = $last_clicks;

because $clicks, being active data, might've changed between creation and 
access time.

>That allows the opcodes to have stable well-known semantics.

What, you don't want a background thread randomly changing opcode 
functions? You're no fun... :-)

                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to