2.1 KiB
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 withconstvalues.val- avalvariable 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- arefis analogous to a full pointer or object reference. Copies of the samerefcan exist in multiple places, and refer to the same object in memory. Changes to data mutated via arefare immediately visible to any other code that has the sameref.
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