On Mon, Feb 15, 2010 at 02:57:10PM -0000, Parrot wrote:
> Third, what do the other Array types do in this instance? Is it just RSA
> that's missing the get_number VTABLE, or are other types missing it as
> well? I would much rather we move in a direction of more consistency among
> array types than less consistancy.
[Answering out of sequence here for clarity]
Most of the other array types default get_number to be calls to get_integer.
In general, I think that any type that provides a get_integer should also
provide a get_number (that can just delegate to get_integer if appropriate).
More below...
> First, seems nonsensical to me to expect an Array to return a floating
> point number in any case. Especially in this case where it seems you want
> Parrot to implicitly cast the integer value to a float.
> [...]
> Second, it seems strange to me that NQP would be forcing all mathematics
> operations to use floating point.
Let me re-frame this discussion in terms of what our dynamic languages
actually need and are trying to do. First, the forcing of mathematics
into floating point is really Parrot's influence, not NQP's.
What NQP, Perl 6, and other dynamic languages want is a way to say
"give me a numeric value for this Object". We really don't care if
that value is an integer, floating point, complex, fraction, or whatever
-- we just want a numeric value that we can use as an argument in a
mathematics operation. (Here I'm using the term "numeric" in its
more generic sense of being number-like, emphatically not in Parrot's
sense of meaning "floating-point".)
In particular, given a HLL statement like...
my $c := $a + $b;
what we're wanting to do is take the numeric value of $a, add that
to the numeric value of $b, and store the result in $c. Or, more
directly:
my $c := +$a;
My point is that it's not the HLL (e.g. NQP) that is requesting
these values to be floating point -- ints would be just fine.
It's Parrot's opcode and vtable set that constrain this to be
a "floating point operation".
The vtable interface that Parrot provides for "give me a numeric
value" is "get_number", which currently casts everything into a
floating point number. For the +$a code above, I clearly can't
have the compiler generate a call to "get_integer", because $a's
numeric value might be something that doesn't fit in an integer.
So, NQP goes with what Parrot _does_ provide, which is to use
"get_number" to obtain a PMC's numeric value.
Any PMC that expects to be usable in a numeric context (including
arrays) therefore needs to supply a get_number vtable operation.
My view the underlying issue isn't that NQP or other languages
are expecting Arrays to return floating point values specifically;
the issue is that we want to be able to ask any generic object
for its numeric representation, and we can't always know in advance
if that object numifies to an integer. So, the best we can do
at the moment is to use get_number as the general interface for
"give me a number". (Clearly we don't want to be asking each
object "what do you prefer" before we do any math on it...
we just want an operation that gives us back a number that
we can do math on.)
It might be nice if there was a PMC form of the get_number
vtable function -- this would enable individual types to
dynamically decide what sort of numeric value to return instead
of constraining the answer to be a something that fits
in an N register. Then an array could always return an
Integer PMC in response to get_number, while a string or
other data type could choose an Integer, Float, or whatever
is best for its particular value.
Pm
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
