Front page | perl.perl6.internals |
Postings from February 2001
Re: PDD 2, vtables
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
-
Re: require < 6.x
by Brent Dax
-
PDD 2, vtables
by Dan Sugalski
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by Branden
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by David Mitchell
-
Re: PDD 2, vtables
by Dan Sugalski
-
Re: PDD 2, vtables
by Simon Cozens
-
Re: PDD 2, vtables
by Dan Sugalski
-
Re: PDD 2, vtables
by Edwin Steiner
-
Re: PDD 2, vtables
by Edwin Steiner
-
Re: PDD 2, vtables
by Dan Sugalski
-
Re: PDD 2, vtables
by Tim Bunce
-
Re: PDD 2, vtables
by Branden