I'm back...
Dan Sugalski
list is keys, defining the extension mechanism, and the exception
infrastructure. We'll go from there.
In the mean time, someone can go ahead and implement the cmps and
cmpi ops to do string and integer compares respectively.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Sean O'Rourke
> In the mean time, someone can go ahead and implement the cmps and
> cmpi ops to do string and integer compares respectively.
Do you mean {gt,ge,eq,ne,le,lt}{s,n} conditional branches, or something
like "cmps Ix, Py, Pz"? Also, would num-comparisons be more useful than
int- ones?
/s
Dan Sugalski
cmps Ix, Py, Pz. And it should be a numeric comparison rather than an
integer one, you're right.
If I thought anyone'd do control flow with it, I'd have a version of
the op for that, but I don't think we're going to see that, and perl
doesn't do it, so...
Sean O'Rourke
> If I thought anyone'd do control flow with it, I'd have a version of
> the op for that, but I don't think we're going to see that, and perl
> doesn't do it, so...
Okay, writing this email has convinced me that maybe we don't need these
ops. If Perl's going to do things like this:
$x = 1; $y = 2; $z = "grape";
if $z < $x < $y lt $z { print "strange, but true" }
then it seems like they'll be used for control flow just like anything
else. The alternative would be to do this with the Ix versions like so:
cmpn I0, Px, Py
unless I0, -1, l_false
Or with the current set of ops, through temps like so:
set N0, Px
set N1, Py
ge N0, N1, l_false
Actually, since with this version we can keep the num/string temporaries
around to reuse them in comparison chains and only do the conversion once,
the other might not be so great -- strtod is painful. cmp{n,s} save us
one instruction per compare (two for the branching versions), so they'd
probably be a win on single comparisons, but they're not as useful as I
naively thought.
How useful do people think these are?
/s
Dan Sugalski
>On Mon, 29 Jul 2002, Dan Sugalski wrote:
>> If I thought anyone'd do control flow with it, I'd have a version of
>> the op for that, but I don't think we're going to see that, and perl
>> doesn't do it, so...
>
>Okay, writing this email has convinced me that maybe we don't need these
>ops. If Perl's going to do things like this:
>
> $x = 1; $y = 2; $z = "grape";
> if $z < $x < $y lt $z { print "strange, but true" }
>
>then it seems like they'll be used for control flow just like anything
>else. The alternative would be to do this with the Ix versions like so:
>
> cmpn I0, Px, Py
> unless I0, -1, l_false
>
>Or with the current set of ops, through temps like so:
>
> set N0, Px
> set N1, Py
> ge N0, N1, l_false
I need to get Larry to nail some things down. On the one hand, he's
said that chained comparisons evaluate their parameters just once.
That argues for moving the values to N or S registers. On the other,
comparisons are overloadable, which means we need to call the PMC's
vtable entries. But chained comparisons will result in us calling
those entries multiple times, when we've been declared to call them
only once.
Hrmf. Time to nudge. Oh. Larry.... :)
Sean O'Rourke
> I need to get Larry to nail some things down. On the one hand, he's
> said that chained comparisons evaluate their parameters just once.
> That argues for moving the values to N or S registers.
I read that as "expressions are evaluated once", not "PMC's are accessed
once". So something like
2 < $i++ < 23
will do the expected -- increment $i once, keeping the result in a PMC
temporary. The temp will necessarily be accessed more than once, but to
me that doesn't count as evaluating the expression multiple times.
> On the other, comparisons are overloadable, which means we need to
> call the PMC's vtable entries.
That gets us into that mess. But we can still evaluate the expression to
a PMC temporary, then get its value more than once. And if you've tied a
variable to have side effects every time it's accessed, you shouldn't care
if the results are unpredictable.
/s
Sean O'Rourke
> And if you've tied a variable to have side effects every time it's
> accessed, you shouldn't care if the results are unpredictable.
s/tied a variable/implemented a type/. Argh.
/s
Graham Barr
> On Tue, 30 Jul 2002, Dan Sugalski wrote:
> > I need to get Larry to nail some things down. On the one hand, he's
> > said that chained comparisons evaluate their parameters just once.
> > That argues for moving the values to N or S registers.
>
> I read that as "expressions are evaluated once", not "PMC's are accessed
> once".
That was my understanding too.
Graham.
Dan Sugalski
If that's true, then I'm happy. (And I can live with being the only
person confused about this, since it doesn't hurt to check)
John Porter
> I read that as "expressions are evaluated once", not "PMC's are accessed
> once". So something like
>
> 2 < $i++ < 23
>
> will do the expected -- increment $i once, keeping the result in a PMC
> temporary.
I don't see that. $i++ increments the original PMC.
2 < $i+1 < 23
needs to create a temporary, and that illustrates your point.
--
John Douglas Porter
Melvin Smith
>Sean O'Rourke wrote:
> > I read that as "expressions are evaluated once", not "PMC's are accessed
> > once". So something like
> >
> > 2 < $i++ < 23
> >
> > will do the expected -- increment $i once, keeping the result in a PMC
> > temporary.
>
>I don't see that. $i++ increments the original PMC.
Here is a 3rd opinion ;)
$i++ is postfix so it evaluates $i in the expression before incrementing,
so you do
need a temporary, but not to hold the result of the increment; to hold
the original value.
-Melvin