On Tue, Apr 11, 2006 at 08:30:09PM +0100, Nicholas Clark wrote:
> On Tue, Apr 11, 2006 at 07:05:33AM -0700, Will Coleda wrote:
>
> > P1 = new .Float
> > P1 = 123
>
> > The assignment of 123 autoconverts the float to an integer, which
> > doesn't support the 'exp' method that's defined in the Float pmc.
> > (Change the 123 to 123. and it works fine.)
>
> I'm not sure which parts of the fine documentation I've failed to read or
> digest, and whether I'm about to criticise something fundamental that
> someone(s) have worked on for a long time, but from reading this message
> alone this whole behaviour just feels plain wrong. Sort of "principle of
> most surprise" It doesn't seem very intuitive that the virtual machine's
> basic types (or at least the ones that have names suggesting that they are
> basic) are built to jump sideways at the least provocation.
Just to add a "me too" of sorts -- I didn't really notice it when
most everything was using "Perl*" PMCs, but now that we've separated
things out into base types the behavior seems very odd, unexpected,
and somewhat undesirable.
The following is also bit unexpected (but at least it's consistent):
.sub main :main
$P1 = new .Integer
assign $P1, 2
#...and other ops on $P1...
$P0 = new .Float
assign $P0, $P1
$S0 = typeof $P0
print $S0 # outputs "Integer" (!)
print "\n"
.end
In short, the only way to get an integer value into a .Float PMC
seems to be to pass it through an N register:
$P1 = new .Integer
# ...
$P0 = new .Float
$N1 = $P1
assign $P0, $N1 # $P0 now remains a .Float
Here I agree with Nicholas -- there may be some invisible
design decisions behind this, but it just feels very wrong.
Pm
