Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Create a get_numeric_pmc VTABLE #552

Open
Whiteknight opened this Issue Feb 20, 2010 · 5 comments

Comments

Projects
None yet
4 participants
Contributor

Whiteknight commented Feb 20, 2010

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.

Originally http://trac.parrot.org/parrot/ticket/1470

Contributor

jkeenan commented Sep 17, 2010

Can anyone take a crack at responding to whiteknight's RFC?

Thank you very much.

kid51

Owner

pmichaud commented Sep 17, 2010

Rakudo and NQP would find this useful, if implemented.

For background, the discussion that lead to this RFC is found in the comments of TT #1445.

Pm

Member

bacek commented Sep 17, 2010

Hello.

Should we also deprecate get_number and get_integer VTABLEs? And introduce get_string_pmc?

-- Bacek

Owner

pmichaud commented Sep 19, 2010

On Fri, Sep 17, 2010 at 05:47:49AM -0000, Parrot wrote:
> #1470: Create a get_numeric_pmc VTABLE
> -------------------------+--------------------------------------------------
>  Reporter:  whiteknight  |       Owner:
>      Type:  RFC          |      Status:  new
>  Priority:  normal       |   Milestone:
> Component:  core         |     Version:  2.1.0
>  Severity:  medium       |    Keywords:
>      Lang:               |       Patch:
>  Platform:               |
> -------------------------+--------------------------------------------------
>
> Comment(by bacek):
>
>  Hello.
>
>  Should we also deprecate get_number and get_integer VTABLEs? And introduce
>  get_string_pmc?
get_string_pmc might be useful.
I would not want to deprecate get_number and get_integer VTABLEs.
Pm
Contributor

jkeenan commented Jun 11, 2011

Do we expect to take action on any of the items discussed in this ticket?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment