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.
Problem:
1. the evaluation of ${ BLOCK } must be done now.
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.)
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.
-Edwin
