Per worked 20h since Day 61.
How do we get a good story for dynamic arrays? What we called stretchy bufs (buf_... API)
Added many new intrinsics to gen_intrinsic:
- apush, kadd, kdget, kdel
- hget, hdel
Which perform some syntactic sugar, and better typechecking on top of existing bare ion code for these functions.
Notes that argument 2 checking for va_arg should be and is being done by the type checker now. (How? My signature uses void argument there, so I don't know how it's done. Maybe void* and finding the original type of the expression?)
New declaration note is @inline, which replaces c preprocessor macros, and allows straight inlining in the resulting code.
body of acat, which is @foreign is resolved and used to generate foreign code. it being intrinsic means it can use compiler support to check the arguments.
I.e. after entering the intrinsic space where type checking is done at the boundary, we're in a decayed, type-erased world where everything is done via void* and explicit sizes.
Call-By-Name adhoc done in intrinsic.
Another new feature are tuples. (like anonymous structs)
New feature:
offset based access to aggregates. I.e.
struct Foo { a: int; b: char; }
foo: Foo; foo[0] -> int foo[1] -> char
goals: no issues with polymorphism goals: no adhoc casting (for usage code)
Given polymorphic support for stretchy, dynamic arrays.
"What if the representation of an associative set (collection on which we can do lookups based on values) was a dynamic array" <=> from the perspective of iterations, you can iterate over the dynamic array. Mutation is done via special intrinsics. <=> I.e. the type of the associative set is "T*"
Guarantees:
- "Insertion order"
- "swap deletion"
a map is an array of {key, value}*
maps are like sets expect only a part is used to do the associative lookup Per uses tuples for it.
<=> Some prefix of bits are used for the lookup
Indexing is decoupled. One could use adaptative indexing.
@timestamp: 1:04:00