I've been rethinking generics (#17) and I don't think they should be in the language.
Before I go into reasons, let me overview some of the design thoughts here:
Arr (Array types, aka a space of memory for one or more of the same type)
I need Arr types in the bootstrapped language: they are necessary for (local) strings as well as lots of other primitives.
I thought I needed generics for Arr types. You would have something like Arr[U1] be a str, and then it's methods would be generated for that type.
I had an idea of how I could do names (and still could do them). You could do someName[SomeType, SomeOtherType]. The parser would construct a linked-list of types and lookup any "name" by key: &CStr, tys: &TyI.
Requiring generics for Arr types basically meant an explosion of complexity in the bootstrapping compiler, and I was starting to get really sad about it. To make matters worse, I felt that to have generics we should also have the "better names" using [...] -- but that requires many things -- including another BBA to store the types we find, specialized BST methods (not hard but definitely more complexity) and increased memory usage on every node, etc.
Arr types
An Arr type is just a contiguous memory region of zero or more of a specific type. Usage includes:
\ Usage in a struct with unknown size
struct CStr [ U1 len; Arr[? U1] dat]
\ Usage as a local with known size for demo purposes
fn foo do (
var s: Arr[12, U1]
var h: Str = |hello world| \ demo of some memory to copy
ptr.move(s, h.dat, h.len)
StdOut.print(Str(s, h.len))
)
I realized that the Arr type can very easily be a "specialized" type. Basically: Arr can be a specialized type because pointers/references are already specialized types. Only a small amount of additional logic needs to be added to support arrays.
It will have a bit in TyI.meta which indicates that it is an array type
Allocating it will bump the offset (struct, local, etc) appropriately. The size itself will not be recorded anywhere else
referencing it will push a pointer to the type onto the stack.
All operations on the "array" are just pointer operations.
Other types (Str for instance) can implement methods -- but under the hood they will all use pointer arithmetic on an Arr field.
I've been rethinking generics (#17) and I don't think they should be in the language.
Before I go into reasons, let me overview some of the design thoughts here:
someName[SomeType, SomeOtherType]. The parser would construct a linked-list of types and lookup any "name" bykey: &CStr, tys: &TyI.Requiring generics for Arr types basically meant an explosion of complexity in the bootstrapping compiler, and I was starting to get really sad about it. To make matters worse, I felt that to have generics we should also have the "better names" using
[...]-- but that requires many things -- including another BBA to store the types we find, specialized BST methods (not hard but definitely more complexity) and increased memory usage on every node, etc.Arr types
An Arr type is just a contiguous memory region of zero or more of a specific type. Usage includes:
I realized that the Arr type can very easily be a "specialized" type. Basically: Arr can be a specialized type because pointers/references are already specialized types. Only a small amount of additional logic needs to be added to support arrays.
Other types (Str for instance) can implement methods -- but under the hood they will all use pointer arithmetic on an Arr field.