Nick Ing-Simmons wrote:
> 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.
Dan suggested that log_or didn't have to short circuit. I guess I was
also reading in how code like
@foo = @bar || some_big_hairy_function();
would work. Does log_or get a lazy second argument? Are lazy arguments
going to be fast enough to implement conditionals?
> >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.
I absolutely agree that || and && need to be over-loadable -- even for
changing the always-short-circuit behavior to DWIM behavior.
My only point is that we shouldn't do this in the vtable. The vtable
IMHO needs consistent and well defined semantics so that other parts of
the system can safely make assumptions about what transformations can
be legally done to the code.
I'd like to see over-loading || done with a macro system. Maybe
something like:
BEGIN {
syntax $expr : $expr || $expr
{
my $t = $1;
(has_method($t, 'op_logical_or')) ? $t->op_logical_or($2)
: ($t) ? $t : $2
}
}
(That should be read as a tree substitution macro with $1 and $2 bound
to the parse trees for the operands of the || operator.)
There could be several macros like this defined by "use overload".
> >IMHO syntax changes (like creating non-short circuiting logicals)
>
> Semantic not syntax.
Maybe you're right. IMHO it's one of those fuzzy boundaries between
the syntax and semantics. An over-loaded || operator is a regular
method call. The non-over-loaded || operator is a special form of
an "if" statement.
- Ken
