Open evincarofautumn opened 11 years ago
I have a prototype which parses C headers and extracts declarations of functions and types. I have decided on the following mapping between C types and Kitten data types.
struct
Data types with one constructor have boxed struct
layout.
data point:
case point (int, int)
struct point {
int field0;
int field1;
};
enum
Data types with one or more constructors with no fields have unboxed enum
layout.
data bool:
case false
case true
enum bool {
false,
true,
};
Data types with multiple constructors with fields have boxed union
of struct
layout:
data number:
case int (int)
case float (float)
union number {
word tag;
struct {
word tag;
int field0;
} case0;
struct {
word tag;
float field1;
} case1;
};
union
Data types with anonymous constructors have union
layout. They are constructed and deconstructed using casts. Unspecified casts are disallowed.
data number:
case (int)
case (float)
1.0 as (number) -> pun;
pun as (int) -> converted;
…
union number {
int case0;
float case1;
};
Kitten’s int
type will be parameterised by a bit size and a signedness. Integer literals may be affixed with a size and/or signedness, which will default to 64 bits and signed, respectively. There is a mapping from Kitten integer types onto C99 integer types via stdint.h
, but the inverse mapping is platform-defined and will require (compile-time) range checks. I would like to have an arbitrary-precision integer type available for correctness purposes, but I am loath to use GMP for licensing reasons. float
will similarly take a bit size.