The current interpreter is built on top of Haskell, and all data values are stored in a Haskell union type with string tags. Even without any optimization or type inference, the interpreter should be operating on (type, value) pairs where type is some description of the type and value is stored in Duck-native format (which will be roughly the same as the Haskell/OCaml/etc. native formats except for closures).
It's essentially impossible to implement correct data layout on top of any language that isn't full TAL (technically speaking, it's likely ATS could do it, but I don't want to spend all my time proving theorems just yet). Therefore, it is probably best to do this along with the translation into LLVM.
This is partially done as of a1de1ff44329e40b0c59c807dc424754eb721664. The interpreter now uses a raw memory layout. It's currently very simplistic, but it's enough for now and probably enough until we self-host.
The current interpreter is built on top of Haskell, and all data values are stored in a Haskell union type with string tags. Even without any optimization or type inference, the interpreter should be operating on (type, value) pairs where type is some description of the type and value is stored in Duck-native format (which will be roughly the same as the Haskell/OCaml/etc. native formats except for closures).
It's essentially impossible to implement correct data layout on top of any language that isn't full TAL (technically speaking, it's likely ATS could do it, but I don't want to spend all my time proving theorems just yet). Therefore, it is probably best to do this along with the translation into LLVM.