You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alucard as a language is quite limited, further the type system is also quite limited. Due to this I'd like to introduce the folloiwng primitives
(type-of foo int)
this states the value foo is of type int, and that we should check if this is consistent
(assume foo int)
This states the value foo is of type int and we are to just assume this as fact
(coerce foo int)
This state that the value foo will now be considered in the format of int
These three have distinct roles. 1. will serve as :: in haskell, 2. will serve as a non checked version of this. And finally 3. will allow us to convert types between each other.
1. and 2. are quite easy to implement as they just tell the type checker of types that can be propagated and checked against.
3. on the other hand can be more troublesome to compile. This is because if we consider the situation where we coerce an integer into a record or vice versa.
For records in particular this is difficult, as records get desugared into multiple values with no packing. Thus to say an integer is a record or a record is an integer would incur a packing cost where we have to shuffle the data to fit the layout of the target data types.
This kind of situation will happen often as to get quick array iteration we will have to resort to this kind of trick [1].
Thus I propse a pass after type checking that looks at these coercesions and determines if any packing or unpacking needs to occur. If no shifting of data is required, we can silently just turn the coerce into a let binding to get removed later. If not we can expand it to the packing or unpacking logic and have the system handle it from there.
[1] Since Alucard's type system distinguishes between sizes of arrays and we lack any sort of depdendent typing, we can't have our recursive primitives work on an array that is decreasing in size. That would be invalid type wise. Thus for efficient array lookup, we'll likely convert the array to an int, and mod off values. Meaning that we'll then coerce the modded off value to the original type the array was composed of.
The text was updated successfully, but these errors were encountered:
Alucard as a language is quite limited, further the type system is also quite limited. Due to this I'd like to introduce the folloiwng primitives
(type-of foo int)
foo
is of type int, and that we should check if this is consistent(assume foo int)
int
and we are to just assume this as fact(coerce foo int)
foo
will now be considered in the format ofint
These three have distinct roles.
1.
will serve as::
in haskell,2.
will serve as a non checked version of this. And finally3.
will allow us to convert types between each other.1.
and2.
are quite easy to implement as they just tell the type checker of types that can be propagated and checked against.3.
on the other hand can be more troublesome to compile. This is because if we consider the situation where we coerce an integer into a record or vice versa.For records in particular this is difficult, as records get desugared into multiple values with no packing. Thus to say an integer is a record or a record is an integer would incur a packing cost where we have to shuffle the data to fit the layout of the target data types.
This kind of situation will happen often as to get quick array iteration we will have to resort to this kind of trick [1].
Thus I propse a pass after type checking that looks at these coercesions and determines if any packing or unpacking needs to occur. If no shifting of data is required, we can silently just turn the coerce into a let binding to get removed later. If not we can expand it to the packing or unpacking logic and have the system handle it from there.
[1] Since Alucard's type system distinguishes between sizes of arrays and we lack any sort of depdendent typing, we can't have our recursive primitives work on an array that is decreasing in size. That would be invalid type wise. Thus for efficient array lookup, we'll likely convert the array to an int, and mod off values. Meaning that we'll then coerce the modded off value to the original type the array was composed of.
The text was updated successfully, but these errors were encountered: