On Fri, Feb 19, 2010 at 11:13:51AM -0500, Andrew Whitworth wrote:
> > my $c := $a + $b;
>
> In this case it's not that we want to just take any old numeric value
> and just store any old numeric type into $c. Far more common are ideas
> of type promotions where $c is an integer if $a and $b are integers,
> and $c is a different type depending on the types of $a and $b and the
> rules of type promotion. If $a and $b are both Integer PMCs, it is
> flat wrong in any language I can think of that $c would become a
> Float.
Agreed fully. The problem is that Parrot opcodes don't give me
this sort of control -- all I have for the above is the various
'add' opcode variants, and the only one that currently fits the
generic meaning of '+' for most of the built-in types is add_n_n_n.
(In particular, the *Array PMCs don't support the VTABLE_add_*
functions that would be needed for using the add_p_p_p opcode here,
and arguably they shouldn't have to do so.)
The more direct explanatory case is the one I gave afterwards...
my $c := +$a;
...how exactly would one represent this in PIR? (The intended
meaning is that $c becomes the numeric representation of $a;
if $a is an Array, we'd like $c to be the number of elements in
the array; if $a is a String, we'd like $c to be the numeric
representation of that String (which might not even be integer
or floating point!), etc.
> My point stands that it is completely nonsensical to ask certain types
> for a floating-point value, and it's completely nonsensical (and
> likely very inconsistent depending on HLL) to ask some types for an
> integer one. NQP is one thing because it's a separate project and I
> won't tell you how to write your code, ...
You've seemingly again made the mischaracterization of NQP as
wanting a "floating-point value". That's explicitly what
I was trying to disclaim in my previous message -- NQP doesn't
want "floating-point value", it wants something that is
arithmetical/numeric. At present all Parrot provides for this
are the "get_integer" and "get_number" vtable functions, and faced
with this choice, NQP settles for get_number simply because it
has the wider range. But the choice of floating-point is imposed
on NQP by Parrot's API, not because NQP inherently wants operations
to be floating point (it emphatically doesn't).
> ...but I am very strong in the
> believe that Parrot should not be forcing these kinds of defaults on
> it's users.
...and my point is that Parrot is forcing these kinds of defaults.
So I think we're agreeing here.
> really mean "floating point number". I think that should change. It's
> not that get_number casts things to a FLOATVAL, it's that the function
> is typedefined to return a FLOATVAL. Hypothetically if we renamed some
> VTABLEs, in the case you described above would you opt to call
> get_integer() or get_float() by default?
My point is that _neither_ of those vtables are a correct default.
NQP uses the "get_float" (get_number) option only because it's
less incorrect in the general case than "get_integer".
In the cases I've describe above, I want to have a vtable function
that means "return me a numeric value" without forcing me into
the false choice of a-priori requesting either an integer or a floating
point. In other words, the caller shouldn't have to predetermine
what kind of number it wants, it should be able to say "give me
a number" and let the callee decide what sort of number (int, float,
fraction, complex, etc.) is appropriate to return. (The caller
then decides what to do with that value, and if it's not something
it knows how to handle, it carps appropriately.)
> Again, hypothetically, what
> if there was a "get_numeric_pmc" (that you also mention below) that
> would return the correct numerical representation of a PMC as another
> PMC (be it an Integer, a Float, a Complex, etc)? Would that help to
> make things a little more type-agnostic and prevent needing to ask an
> array for it's floating-point value in the examples you posted?
Yes, it would be a big help.
> Second, Parrot needs a way to get a "proper" numerical value from a
> PMC which is suitable for use in numerical calculations like you
> mention above. This could come in one of two ways: Either asking the
> PMC whether it is int-like or float-like, or asking it for a numeric
> PMC type and delegating mathematic operations to that PMC.
The first approach (ask the PMC for int/float) is wrong on several
levels, so the correct approach is ask it for a numeric PMC and delegate
to that PMC.
> It should not be Parrot's place
> to make the decision on a global level and say that all PMCs default
> to returning a floating point value in a mathematical context.
Agreed. It should also not be Parrot's place to say that a caller
must decide beforehand if it wants an integer or floating point
representation.
> > 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.
>
> I like this idea the best, and will open a ticket to request it.
NQP (and Rakudo) will benefit a great deal from this, I think.
Pm
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
