Closed evincarofautumn closed 7 years ago
At the moment, [1, 2, 3] :: [int] is represented as:
[1, 2, 3] :: [int]
[type=K_VECTOR] [data ]-->[refcount] [begin ]----->[type=K_INT] [end ]---+ [data=1 ] [capacity]-+ | [type=K_INT] | | [data=2 ] | | [type=K_INT] | | [data=3 ] | +->[... ] | [... ] +--->
We can move the type tag into the vector data block to avoid repeating it for each element:
[type=K_UNBOXED_VECTOR] [data ]-->[refcount ] [type=K_INT] [begin ]----->[data=1 ] [end ]---+ [data=2 ] [capacity ]-+ | [data=3 ] | +->[... ] +--->
This requires changing the representation of K_NONE and K_SOME:
K_NONE
K_SOME
[type=K_NONE] [type=K_SOME] [data=0 ] [data ]-->[...]
To a generic K_OPTION with a nullable pointer:
K_OPTION
[type=K_OPTION] [type=K_OPTION] [data=NULL ] [data ]-->[...]
Similarly, choices should be restructured to place the tag in the KBox instead of in the type field. This shouldn’t be too much of a performance issue, since matching on choices usually needs to load the box anyway.
KBox
type
At the moment,
[1, 2, 3] :: [int]
is represented as:We can move the type tag into the vector data block to avoid repeating it for each element:
This requires changing the representation of
K_NONE
andK_SOME
:To a generic
K_OPTION
with a nullable pointer:Similarly, choices should be restructured to place the tag in the
KBox
instead of in thetype
field. This shouldn’t be too much of a performance issue, since matching on choices usually needs to load the box anyway.