On Fri, 6 Dec 2002, Dan Sugalski wrote:
At 5:47 PM -0500 12/3/02, David Robins wrote:
Adding an extra knob doesn't seem like all that good a solution (seems
you'd run into weird issues, like a boolean PMC that was both true and
false at the same time, or an undef value that was true);
On Sat, 7 Dec 2002, Alex Gough wrote:
[Fri, Dec 06, 2002 at 05:01:21PM -0500: Dan Sugalski]
- have not P0, P1 set P0 to $1-get_bool ? true : false
Sure, that works. I can't think of a good reason to have PMCs be able
to return something fancier than true or false when we ask
On Dec-09, David Robins wrote:
If I may be so bold as to say it, maybe the PMC design shouldn't be closed
just yet.
I don't think it is. I may be wrong, but I think the only thing Dan
was trying to close was the internal structure of PMCs, not the exact
implementations. I think there are
At 12:27 AM + 12/7/02, Alex Gough wrote:
That is to say, in if ( !exp1 ) { ... }, !exp1 merely has to be true
or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
things.
D'oh! Now it's obvious.
I've been conflating the two, which is wrong.
The get_bool vtable method is
On Mon, 9 Dec 2002, Dan Sugalski wrote:
At 12:27 AM + 12/7/02, Alex Gough wrote:
That is to say, in if ( !exp1 ) { ... }, !exp1 merely has to be true
or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
things.
D'oh! Now it's obvious.
I've been conflating the two,
At 9:58 AM -0800 12/9/02, Steve Fink wrote:
On Dec-09, David Robins wrote:
If I may be so bold as to say it, maybe the PMC design shouldn't be closed
just yet.
I don't think it is. I may be wrong, but I think the only thing Dan
was trying to close was the internal structure of PMCs, not the
At 6:58 PM -0500 12/9/02, David Robins wrote:
On Mon, 9 Dec 2002, Dan Sugalski wrote:
At 12:27 AM + 12/7/02, Alex Gough wrote:
That is to say, in if ( !exp1 ) { ... }, !exp1 merely has to be true
or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
things.
D'oh! Now
On Fri, Dec 06, 2002 at 05:01:21PM -0500, Dan Sugalski wrote:
It is OK for an undef value to be true, though. That's not only
allowable, it has to be allowed. For perl, at least, it's how Larry
plans on getting around the function returns undef, but it's a real
undef value, not a false 'I
At 5:47 PM -0500 12/3/02, David Robins wrote:
On Tue, 3 Dec 2002, Dan Sugalski wrote:
At 4:29 PM -0500 12/3/02, David Robins wrote:
Enlightenment appreciated as always.
This is something that'll come up with perl 6 reasonably soon as
well. The solution for us is to have truth and falsehood
[Fri, Dec 06, 2002 at 05:01:21PM -0500: Dan Sugalski]
At 5:47 PM -0500 12/3/02, David Robins wrote:
On Tue, 3 Dec 2002, Dan Sugalski wrote:
- create immutable true and false PMCs
That's fine.
- have not P0, P1 set P0 to $1-get_bool ? true : false
Sure, that works. I can't think of
Yes, me again
Most of the time, in the PMC logical_not method, one can write:
void logical_not (PMC* dest) {
dest-vtable-set_integer_native(INTERP,dest,NOT_SELF);
}
where NOT_SELF is 0 if we're true and 1 if we're false. Or just leave
it out and let default blow up if we're
At 4:29 PM -0500 12/3/02, David Robins wrote:
Enlightenment appreciated as always.
This is something that'll come up with perl 6 reasonably soon as
well. The solution for us is to have truth and falsehood be an
optional property on the variable, potentially separate from the
variable's
On Tue, 3 Dec 2002, Dan Sugalski wrote:
At 4:29 PM -0500 12/3/02, David Robins wrote:
Enlightenment appreciated as always.
This is something that'll come up with perl 6 reasonably soon as
well. The solution for us is to have truth and falsehood be an
optional property on the variable,
13 matches
Mail list logo
