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); why not -
>
> True, but I'm looking at the boolean state of a variable as
> potentially part of a larger set of things. I freely admit a boolean
> PMC with a true value and a false property would be really bizarre.
> (So I'd suggest that you make it so that can't happen... :)
The existing get_bool should suffice for a boolean value, no?
I understand that in the perl language the user should be free to do
anything, and the implementers make it Do The Right Thing, but in a backend
interface there should be a few more constraints, because you know "can't
happen" will.
[snip]
> >- 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 them for
> their logical negation. (Can any language override logical negation
> to return something besides true/false?)
>
> >- and P0, P1, P2 set P0 to $1->get_bool ? $2->get_bool ? $2 : $1
> > : false
> >- or P0, P1, P2 set P0 to $1->get_bool ? $1
> > : $2->get_bool ? $2 : false
> >- xor P0, P1, P2 set P0 to whichever is set, false if both/neither
>
> Not for these, though. Logical and, or, and xor need to be delegated
> to the PMCs as they may be overridden, and binary logical operations
> may return something other than a plain true or false value.
> Otherwise perl's short-circuiting logical stuff behaves... oddly. And
> I know that can be overridden.
Since and/or are _defined_ to short-circuit (in old core_ops.pod or
core.ops), it should suffice to use get_bool, e.g. for and:
call $1->get_bool, if it returns false, return "false PMC" and end op;
call $2->get_bool, return "false PMC" if false, or $2 itself if true.
change return "false PMC" to 0 and $2 to 1 for the Ix dest. version.
If it happens that either PMC represents, say, a call to a function, then
the get_bool method can invoke it (side effect), as in '$x = foo() and
bar()'.
> >- plus optionally allow a not Ix, Px op which sets Ix to 1 or 0, etc.
>
> Maybe. Would any compiler actually use this, though? I don't often
> care about what opcodes we put in, but apparently today I do.
Well, the case that brought it up was trying to do "if" for Ruby. I started
by using not P0/if P0, then I went with unless instead, but it still stuck
out that the logical ops were rather broken because of the dest problem,
i.e., that the dest can be any PMC type and the logical ops have no
guarantee of what it is or what "set_integer" will do to its truth value
(even a "set_bool" wouldn't properly fix this in all cases).
Perhaps the best fix would be to allow the logical ops to return a completely
new PMC. It makes no sense to me for them to have to write to an existing
PMC which could be (say) an array, hash, "integer that is always true"
(Ruby), etc. i.e. pass in dest as a PMC**, if that works.
Of course this applies to other ops too, e.g. PerlInt's add should create a
new perlint that is the sum of self and the rhs most of the time, except in
some cases where it should create a float... ooh, that's gonna be
interesting:
PerlInt + RubyInt => either, might as well favour the lhs
PerlInt + PerlFloat => should return PerlFloat
PerlInt + RubyFloat => ??? (should be a float, but how does perlint.add
check the rhs is more precise?)
RubyFloat + PerlInt => probably RubyFloat, which is OK
....
(Just using Ruby just as an example of an internally-unknown float/int set.)
Should ops like + be affected by argument order? (I was taught + is
commutative....) I see PerlInt is doing all sorta of vtable-comparing,
which is fine for the guys you know but doesn't fly for foreign floats.
It's a problem whether the dest is specified (as now) and just needs to be
set, or is a PMC** and can be created - who picks the dest type and how?
If I may be so bold as to say it, maybe the PMC design shouldn't be closed
just yet.
Dave
Isa. 40:31
