54 lines
2.1 KiB
Markdown
54 lines
2.1 KiB
Markdown
|
# type system
|
||
|
|
|
||
|
|
data types:
|
||
|
|
|
||
|
|
i64, f64 - numbers
|
||
|
|
bool - logical boolean values
|
||
|
|
{fn [type1 type2 ... -> rettype]}
|
||
|
|
|
||
|
|
{array [type length]}
|
||
|
|
|
||
|
|
(struct name
|
||
|
|
^type1 member1
|
||
|
|
^type2 member2
|
||
|
|
^type3 member3)
|
||
|
|
{tuple [^{name member1} type1 ^{name member2} type2 ^{name member3} type3]}
|
||
|
|
|
||
|
|
(enum name
|
||
|
|
(clause1 type1 type2 ...)
|
||
|
|
(clause2 type1 type2 ...)
|
||
|
|
clause3)
|
||
|
|
{variant [^{tuple [type1 type2 ...]} clause1
|
||
|
|
^{tuple [type1 type2 ...]} clause2
|
||
|
|
^void clause3]}
|
||
|
|
|
||
|
|
(protocol name
|
||
|
|
(method name [self ^type1 arg1 ^type2 arg2 -> rettype]))
|
||
|
|
|
||
|
|
(impl protocol type
|
||
|
|
(method name [self ^type1 arg1 ^type2 arg2 -> rettype]
|
||
|
|
body...))
|
||
|
|
|
||
|
|
Variables have both a datatype and an isolation modifier. There are three possible isolation types:
|
||
|
|
|
||
|
|
* `const` - this is the default, if no isolation modifier is given. No in-place mutations are possible with `const` values.
|
||
|
|
* `val` - a `val` variable can be mutated in-place, but changes _only_ affect that variable. If it is assigned to any other
|
||
|
|
variable or passed as a parameter, it is copied if necessary and can be treated as a new, totally distinct value.
|
||
|
|
* `ref` - a `ref` is analogous to a full pointer or object reference. Copies of the same `ref` can exist in multiple places,
|
||
|
|
and refer to the same object in memory. Changes to data mutated via a `ref` are immediately visible to any other
|
||
|
|
code that has the same `ref`.
|
||
|
|
|
||
|
|
When defining data structures, individual members can be annotated as `ref`, but not `const` or `val` - only the structure
|
||
|
|
as a whole can be `const` or `val`.
|
||
|
|
|
||
|
|
Q: should `const` structures be able to modify `ref` members directly? leaning towards yes. `ref` seems to inherently imply
|
||
|
|
interior mutability.
|
||
|
|
|
||
|
|
# memory management
|
||
|
|
|
||
|
|
* "hot reload" implies "given the previous source code and a memory, I can reason about the types of everything in the memory"
|
||
|
|
* compacting garbage collection is simply the degenerate case of rearranging memory to be legible to new code!
|
||
|
|
* we have typed roots (globals), and we can follow typed references from there
|
||
|
|
* stack is not accessible from wasm, and GC / reload would only happen when wasm code returns to JS - no suspension
|
||
|
|
|