#1470: Create a get_numeric_pmc VTABLE
-------------------------+--------------------------------------------------
 Reporter:  whiteknight  |       Owner:       
     Type:  RFC          |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  none         |     Version:  2.1.0
 Severity:  medium       |    Keywords:       
     Lang:               |       Patch:       
 Platform:               |  
-------------------------+--------------------------------------------------
 the get_integer and get_number VTABLEs are limited because they return a
 particular numeric type without any indication for the preference of the
 PMC. For instance, some PMCs may prefer to be treated as an integer value
 or as a floating point value for mathematical calculations. Also, it is
 nonsensical to ask certain PMCs for a floating-point value or to ask other
 types for an integral value.

 If you look at a code example from an HLL like this:
 {{{
 $c = $a + $b
 }}}
 it is difficult to know how to treat the operation and whether to store an
 int-like or float-like value in $c. This is especially true when
 considering types that aren't typically used in equations, such as array
 types. When treated as a number, should ResizablePMCArray act like a float
 or an int? For example NQP treats all mathematic operations as float-point
 and requests values from PMCs accordingly.

 I would like to suggest the creation of a get_numeric_pmc VTABLE that
 would return a numeric PMC type that can be used as a stand-in for a non-
 numeric type in calculations and preserve information about whether the
 type should be treated as a float or an int. An RPA could return an
 Integer PMC as we expect, but other types that prefer it could return
 Float, BigInt, BigNum, or even Complex types as required. In this way we
 could get proper information about the use of a PMC in a mathematical
 context without having to shoehorn unnecessary and nonsensical get_number
 and get_integer vtables into all our types, an without requiring Parrot to
 make decisions about type conversion or type promotion. The HLLs should
 handle those kinds of decisions without Parrot making defaults.

 In additon to the new VTABLE we would likely need a new opcode to expose
 it.

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/1470>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to