Ken Fox <[EMAIL PROTECTED]> writes:
>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 --
And what above suggests it does not?
It is up to bar's log_or not to evaluate baz if bar is considered true.
>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 already does and it is a pain when you are trying to give meaning
to && and || for overloaded objects.
I happend to have a 'need' for || / && which "short circuit later" i.e.
my $result = $obj1 || $obj2; # looks at both and builds "tree"
# perhaps this $obj1->become_false;
if ($result) { ... } # does $obj1->value || $obj2->value NOW
>
>IMHO syntax changes (like creating non-short circuiting logicals)
Semantic not syntax.
>need to
>be done above the opcode level before the optimizer or compiler sees anything.
>That allows the opcodes to have stable well-known semantics.
Agreed - but the vtable scheme above does not preclude that.
>
>- Ken
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
