Instead of wrapping primitive types like Int64 with classes like TInteger, they should be exposed directly to Myst as the native types in Crystal. This would do a few nice things:
Vastly improve performance of primitive operations. Primitives are Values in Crystal, rather than References. As such, they can be allocated on the stack rather than the heap (less time spent allocating memory), take less space in general (8-byte value vs 8-byte pointer + object data), and do not need to be dereferenced.
Native Library methods no longer need to unwrap values to work with them. Lots of code in the native library is cluttered with .value calls on arguments. This wouldn't be necessary if the values were already the native Crystal types.
Faster numeric operations. Without needing to wrap and unwrap values, numeric operations are as simple as the single hardware instruction that implements them, rather than instructions to unwrap, operate, and re-wrap values.
There are a few caveats with using native types, though:
Symbol still needs to be a wrapped type, to preserve the name of the symbol at runtime.
Nil should probably still be wrapped into a singleton, to avoid confusion with native Crystal methods that return nil.
Type lookup needs to change slightly to handle these primitive types that won't have the type_name property.
Primitive types will not have ivars available to them, which would require some assertions from the interpreter.
Instead of wrapping primitive types like
Int64
with classes likeTInteger
, they should be exposed directly to Myst as the native types in Crystal. This would do a few nice things:Value
s in Crystal, rather thanReference
s. As such, they can be allocated on the stack rather than the heap (less time spent allocating memory), take less space in general (8-byte value vs 8-byte pointer + object data), and do not need to be dereferenced..value
calls on arguments. This wouldn't be necessary if the values were already the native Crystal types.There are a few caveats with using native types, though:
Symbol
still needs to be a wrapped type, to preserve the name of the symbol at runtime.Nil
should probably still be wrapped into a singleton, to avoid confusion with native Crystal methods that returnnil
.type_name
property.ivars
available to them, which would require some assertions from the interpreter.