Details
-
Enhancement
-
Resolution: Duplicate
-
P3
-
None
-
7, 9, 10
-
generic
-
generic
Description
http://blogs.sun.com/jrose/entry/tuples_in_the_vm
The Java language and VM provide a flexible object model, with subclassing, interfaces, generically typed containers, and both mutable and immutable objects. They also provide a basic set of primitive types, which map efficiently and predictably to hardware operations.
The primitive types are limited to 64 bits in size, and so cannot represent the information content of important data types, such as pixels, complex numbers, and (short-SIMD) vectors. In addition, even if there were (say) a long-long type added, it would not be possible to program with all of those data types in a type-safe manner.
Small fixed-sized value-oriented types like vectors are called "structs" in the C family of languages. (Note that structs do not have to be homogeneous like vectors.) Taking a JVM-centric point of view, we may interpret this concept in the JVM as "tuples" of pre-existing supported types, the references and primitives.
The current workaround for tuples is to require the programmer to box them in either arrays (for homogeneous tuples only) or in small (often final and read-only) objects. These workarounds are awkward to code with and do not have predictable performance models (even with escape analysis optimization).
There are additional problems due to the lack of tuples:
- impossible to return multiple values from methods
- impossible to build patterned heterogeneous arrays (for optimized data structures)
- no credible numeric stack on the JVM which includes complex or transform types
- many APIs work directly with "int" types with implicit typing, losing static checking
We propose a general solution for these problems in the form of tuple types:
- extension to method, field, and array component signature repertoire
- tuple types have a nominal tag for type safety (e.g., ints with units)
- as in C, calling sequences are purely value oriented
- there is a standard framework of wrapper classes supported by the JVM, for autoboxing conversions
The Java language and VM provide a flexible object model, with subclassing, interfaces, generically typed containers, and both mutable and immutable objects. They also provide a basic set of primitive types, which map efficiently and predictably to hardware operations.
The primitive types are limited to 64 bits in size, and so cannot represent the information content of important data types, such as pixels, complex numbers, and (short-SIMD) vectors. In addition, even if there were (say) a long-long type added, it would not be possible to program with all of those data types in a type-safe manner.
Small fixed-sized value-oriented types like vectors are called "structs" in the C family of languages. (Note that structs do not have to be homogeneous like vectors.) Taking a JVM-centric point of view, we may interpret this concept in the JVM as "tuples" of pre-existing supported types, the references and primitives.
The current workaround for tuples is to require the programmer to box them in either arrays (for homogeneous tuples only) or in small (often final and read-only) objects. These workarounds are awkward to code with and do not have predictable performance models (even with escape analysis optimization).
There are additional problems due to the lack of tuples:
- impossible to return multiple values from methods
- impossible to build patterned heterogeneous arrays (for optimized data structures)
- no credible numeric stack on the JVM which includes complex or transform types
- many APIs work directly with "int" types with implicit typing, losing static checking
We propose a general solution for these problems in the form of tuple types:
- extension to method, field, and array component signature repertoire
- tuple types have a nominal tag for type safety (e.g., ints with units)
- as in C, calling sequences are purely value oriented
- there is a standard framework of wrapper classes supported by the JVM, for autoboxing conversions