Re: A taxonomy of types
- From: James Harris <james.harris.1@xxxxxxxxxxxxxx>
- Date: Tue, 10 Feb 2009 03:31:26 -0800 (PST)
On 29 Jan, 13:27, James Harris <james.harri...@xxxxxxxxxxxxxx> wrote:
Further to the other thread on first-class types it seems there is no
standard representation of a type. For my own language at least I need
to come up with one so I thought it worth writing my ideas here in
case anyone else wants to do similar or share ideas.
Before a representation is practical I think we need a taxonomy (so we
know what we have to represent). Hence this post.
The first issue to consider, ISTM, is that we use types to refer not
just to fully specified in-memory objects (such as "32-bit unsigned
integers") but we also use types to refer to more conceptual objects
which are only partially specified such as incoming parameters. For
example, if I write a function in my language to accept unsigned
integers I know I can pass it unsigned integers of 16 bits or 32 bits
etc. A more familiar example is C where we specify int knowing that it
can represent an integer of 16 bits or more. So, we need to be able to
represent types of not just concrete objects but also conceptual ones.
Second, there are other characteristics that we don't specify but
which are nevertheless part of certain types. Some languages permit
dynamic typing or type inference and most languages have rules
compatibility between types, usually name or structural. These are
implicit characteristics I could ignore them but it would be good to
see if it's possible to get to a general type representation.
Does that make sense so far? There are other fun issues to address but
they can be brought in later. To start here is a beginning to the
taxonomy.
What follows is a longer set of types. I've fleshed it out a bit based
on comments. As someone pointed out there is a need for _IEEE754_
floating point types in addition to generic ones as the IEEE standard
implies a specific set of operations.
Before I get to the list it's worth saying where this seems to be
heading. Since each type has a number of attributes it seems likely
that the representation of a type will be based on a struct or record.
An integer type, for example, may be specified
struct integer_type {
int bit_width;
bool signedness; /* 0=>unsigned, 1=>signed */
... etc ...
}
This is simplified as it doesn't include the various attributes that
languages put on integers but it illustrates the point. For example, a
16-bit signed integer type using the above would be specified as
integer_type{16, 1}.
Also, where the type can be one of many types there would be a _union_
of the possible types. The union would need a tag (a small integer) to
identify which of the types was being used.
Finally, there would need to be built-in types that are universally
recognised (such as integer_type or ieee_float_type or bit_type) and
there would need to be constructed types. The constructed types could
include homogeneous sequences such as arrays and heterogeneous
collections such as records. Further, user-defined types include
method code (using oo jargon) so it too would would need to be
included as part of the type.
..
..
Type taxonomy
=== Integers
Sign
Signed or unsigned or sign unspecified
Fixed size integer (number of bits)
Bounded size integer (low and high number of bits or indefinite)
Checks needed
Type compatibility
=== Floating point numbers - IEEE
Width - 32, 64 etc
=== Floating point numbers - generic
Sign
Not needed (all floating point values are signed)
Exponent base - 2 or 16
Fixed sizes
Exponent size
Mantissa size
Bounded sizes
Exponent size range
Mantissa size range
Comparison limits
Type compatibility
=== References
Type of reference (e.g pointer)
Target domain of reference (e.g. memory)
Key (e.g. address pointed at)
Referenced data type
=== Sequences
Note of whether homogeneous or heterogeneous
Arrays
Lists
Tuples
=== Homogeneous arrays
Element type
Step between elements (greater than or equal to element size)
Low bound
High bound
Single part (i.e. contiguous) or multipart
If multipart a reference to the controlling structure
=== Homogeneous sparse arrays
Element type
Step between adjacent elements
Reference to the controlling structure - a hash or tree
Orderable (if a tree) or random (if a hash)
=== Records (heterogeneous)
Sequence of component types and names
Access rules
By name only
By field number only
Number and name both allowed
Reference to component index if access by number allowed
=== Functions
Sequence of parameters
Sequence of results
Sequence of entry points (if any)
Internal data types
Executable code
=== Object orientated objects
Data
Private
Protected
Public
Executable
Methods (executable code)
Inheritance
Where would first-class types be used? Some options are
- the symbol table of a compiler
- within code such as if X is an instance of type T
- for dynamic creation of objects (of a passed-in type)
I grant you most people won't want the effort of supporting arbitrary
types such as suggested above but I would like to allow persistent
storage of types (amongst other things).
James
.
- Prev by Date: ECOOP 2009: CALL FOR Posters/Demos
- Next by Date: Re: A taxonomy of types
- Previous by thread: Re: A taxonomy of types
- Next by thread: Re: A taxonomy of types
- Index(es):
Relevant Pages
|
Loading
