develooper Front page | perl.perl6.internals | Postings from February 2001

Re: PDD 2, vtables

From:
Edwin Steiner
Date:
February 8, 2001 02:56
Subject:
Re: PDD 2, vtables
Message ID:
3A827BA0.2B05CC43@net4you.co.at
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

nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About