Karl Meakin

> Do you mean in the semantic domain (i.e. `core::semantics::Value`)? Like how I use `Lazy.t` [here](https://github.com/brendanzab/language-garden/blob/cb476cbce2a160093ee58c2249ce26b9ebc6cf22/elab-dependent/lib/Core.ml#L272-L288)? Or having explicit laziness in Fathom itself? Just in the semantic domain for now....

> I think yeah, if we wanted to do this we might need to use some sort of defunctionalised approach – is that what I had in Pikelet? Doesn't matter...

Actually, I was able to fix the lifetime errors: just required being explicit about lifetimes in some `fn` signatures that previously kept lifetimes implicit

What about local imports? `local import fathom.u32be; foo` would function like `let`. Alternatively, we could have an expression version of `import`, which would be more orthogonal and not requre another...

> Changing allocator will require reallocating. But if backing allocator is `&Scope` it is possible to just leak https://doc.rust-lang.org/std/vec/struct.Vec.html#method.leak I haven't examined the internals too closely, but why cant the...

> Interesting thought. So you suggest `Scope` to take ownership of the memory. This is possible with a restriction - `Scope` and `Vec` use `Global` allocator. Otherwise it would be...

Removing `if` would also allow us to have an `(if )` expression

I'd be interested in contributing to this, but I'll have to check with my employer first since it is under a separate repo. In the meantime, you can use the...

> define_opcode_handler! { > fn xadd32( > state: &mut MachineState, > mut pc: UnsafeBytecodeStream, > ) { > // The `decode` module will need to be extended with methods to...

Oh and how can we verify that the tailcall optimization does indeed result in the desired assembly (ie each opcode handler does an indirect branch to the next handler, rather...