Re: PDD 2, vtables

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

From:

Edwin Steiner

Date:

February 8, 2001 12:23

Subject:

Re: PDD 2, vtables

Message ID:

3A830073.2558D86A@net4you.co.at

Dan Sugalski wrote:
> 
> 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.

That would be perfectly fine, I think.
Would the sub (itself, not the reference) be a PMC?
Either way you still need a means to evaluate/call this thing.
I thought there should be virtual functions for this on the
ref PMC or on the sub PMC itself. Is this a misconception?

> 
> >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.

I didn't express myself clearly. I was (unfortunately not explicitly)
refering to the case when the left side evaluates to false, and only
to this case. By "now" I meant after the evaluation of the left side
(to false) and before the assignment.

The problem I was pointing out is triggering the delayed evaluation "now"
(probably by calling a get_* function)
without forcing the result to be one of (integer/number/string/bool).

You suggest making it an anon-sub-ref call, which is fine. But as I stated
above I expected there would be virtual functions for this.
After all the internals of a PMC should only be known to the
virtual functions, right? (eg. Where the ref PMC stores the function/sub
pointer would be internal.)

Your words (PDD 2):
    Nothing outside
    the core of perl (in fact, nothing outside the data type's vtable
    routines) should infer anything about a PMC. (hence the Magic part)

> 
> >     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.

Exactly. I actually found that what I meant (in this example) is described as
"don't-care scalar context" in the Camel Book.

I was troubled because in the PDD there are only get_* functions
for more specific cases (int,number,string,bool).

> 
> >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.

-Edwin