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! N
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 e
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 th
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 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 alrea
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
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 tru
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
[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.
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
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,
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 value.
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
13 matches
Mail list logo
