At 03:56 PM 9/13/00 -0400, Ken Fox wrote:
>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?
The second argument would have to be taken as a list, and I hadn't much
considered that case. I've been thinking that lists should be considered
perl primitives under the hood, and this is another good argument for that.
> > >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.
Speed, consistency, and ease of overloading are the reasons I'd like it in
the vtable, though I may well be completely missing the mark here. (Not
that it'd be the first time... :)
>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.)
Yech. (And I say that with deep conviction... :) Though it may be a
reasonable way to do it.
> > >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.
I'd rather they be treated the same, otherwise it means more work at
runtime to know which way to handle it. (Since we can't reliably tell at
compile time whether something's overloaded or not)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
