On Fri, Feb 19, 2010 at 10:39 AM, Patrick R. Michaud <[email protected]> wrote: > 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...
On one hand, I like the idea of consistency and if "all the other cool kids are doing it", I don't see a problem with RSA doing the same thing as well, for consistency's sake. > 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. That said we can obviously do some rudimentary checks, like if $a is an Integer PMC, and $b is an Integer PMC, that $c likewise is an Integer. But the waters get more murkey when we consider a myriad of HLL-mapped integral types, some of which may choose not to cleanly derive from Integer. In those cases it's prudent to ask whether the PMC is int-like or float-like and handle it accordingly. 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, but I am very strong in the believe that Parrot should not be forcing these kinds of defaults on it's users. > 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".) > > ... > > 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. So this really is a conflation of two separate issues. First, Parrot really is misusing the term "number" in the context of VTABLEs to 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? 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? In the way Parrot is currently set up, get_number() is explicitly a request for a floating-point value and is treated as such throughout the core repository. get_integer() is likewise an explicit request for an INTVAL. We also don't have a way to even ask a PMC which of the two it prefers, a choice which can have some very real relevance when the type is expected to be used in calculations, especially calculations performed by externally-loaded libraries, such as dynop libraries. 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. > 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.) I would suggest that numifying to an integer is the far more common operation when you consider things like counters, loop sentinels, and array indices in most programming language. But, that's a semantic issue that isn't worth discussion. Is the question "how to get any math-suitable numeric value?" or "how to get the correct math-suitable numeric value?". The two questions often will have very different answers, especially in different HLLs. 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. > 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. I like this idea the best, and will open a ticket to request it. --Andrew Whitworth _______________________________________________ parrot-tickets mailing list [email protected] http://lists.parrot.org/mailman/listinfo/parrot-tickets
