strict sto

[mhuesch]

this PR builds on #33, as explained in #33.

summary of changes

this is a preliminary PR which adds a Sto (short for store) to the strict interpreter. this is another layer of indirection. the TermEnv now maps Names to indices in the Sto, which in turn maps indices to Values (before, the TermEnv mapped Names directly to Values).

Value

in order to make this change we must parameterize Value by the type it recursively contains. it no longer simply wraps itself, because there are now two cases for Value: (1) a value whose recursion is "mediated by the Sto", and therefore requires a Sto to be semantically meaningful/coherent; (2) a value whose recursion is self-contained (this is what Value was prior to these changes). (1) is Value<VRef>, (2) is FlatValue. since VRef is essentially a pointer to a memory address, we are now mediating recursion through the Sto.

old Value:

pub enum Value {
    VInt(i64),
    VBool(bool),
    VClosure(Name, Box<Expr>, TermEnv),
    VCons(Box<Value>, Box<Value>),
    VNil,
    VPair(Box<Value>, Box<Value>),
}

new Value and associated types (clipped down a bit from the code in eval.rs):

pub struct VRef(usize);

pub enum Value<R> {
    VInt(i64),
    VBool(bool),
    VClosure(Name, Box<Expr>, TermEnv),
    VCons(R, R),
    VNil,
    VPair(R, R),
}

pub struct FlatValue(pub Value<Box<FlatValue>>);

type TermEnv = BTreeMap<Name, VRef>;

pub struct Sto {
    pub sto_vec: Vec<Value<VRef>>,
    pub sto_ev_map: HashMap<u64, usize>,
}

we observe that Value no longer directly recurs on itself. and because it is polymorphic in R, we can instantiate in the ways described above as (1) and (2).

de-duplication

another interesting change here is de-duplication of Sto values based on Hashes. when Values were mapped in the TermEnv directly, a program could end up doing a lot of cloning/copying. let-binding a variable, for example, would copy the whole Value.

(let ([a true]
      [b a])
  b)

since we have purity & referential transparency in our language, we can instead do sharing of values in the Sto. in the example above, both a and b would be mapped by the TermEnv to the same memory address, which would contain VBool(true).

de-duplication essentially hashes each value that goes into the Sto, and checks whether we have already mapped that value in the Sto. if it is already present, instead of allocating a new address to house that value, we simply return the existing address. there is a tradeoff here between computation (hashing) and memory - my hunch is that it's worth it.