At 11:57 AM 2/8/2001 +0100, Edwin Steiner wrote:
>Dan Sugalski wrote:
> > At 04:02 PM 2/7/2001 +0000, David Mitchell wrote:
> > > > >Please see my previous post on the subject. As I pointed there,
> > > implementing
> > > > >|| and && like that breaks short-circuits.
> > > >
> > > > No, it doesn't. Just because you pass in two PMCs doesn't mean that 
> they
> > > > both need to be evaluated. Though the PDD does need to be clearer 
> about
> > > how
> > > > that happens.
> > >
> > >Hmmm, I can't quite how that trick works. How whould the following get
> > >evaluated:
> > >
> > >$opened || open(F, ...)
> >
> > The second PMC would point to a lazy list, so it wouldn't be evaluated
> > unless its value gets fetched.
>
>This implies there will be PMCs containing or refering to an arbitrary
>amount of bytecode (with delayed execution). Consider this:
>
>     $dest = $i || ${ BLOCK };
>
>I wonder which vtable function $i->logical_or will use to trigger the
>delayed evaluation of the right operand. (I assume it will be evaluated
>before the assignment.) The only thing $i->logical_or can know about
>${ BLOCK } is that it will be something scalar.

What we can do in that case is treat the right-hand block as an anonymous 
sub, and put a code ref in the list for the righthand side.

>Problem:
>     1. the evaluation of ${ BLOCK } must be done now.

Must it? Lazy evaluation would lead me to think it shouldn't be done unless 
the left side of the || evaluates to something false.

>     2. the result should not be forced to a certain type, because
>        || doesn't do this. (Contrary to arithmetic operators the
>        left operand $i has nothing to say in this.)

Well, the right side of || gets the context of the left side of the 
assignment, if it's in one. But dealing with odd context isn't anything new 
in perl.

>I don't see any vtable functions in the PDD which could solve this.
>Maybe there should be
>     get_scalar and
>     get_list
>functions, which do not force anything but evaluation in scalar/list
>context.

Context is set separately, and I'm not sure how to do it yet. I'm 
considering some sort of interpreter variable with the current context, but 
I'm not sure that's the best way.

We will need utility functions to find it out, though.

                                        Dan

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

Reply via email to