You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
This is partially done as of a1de1ff. 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.
The text was updated successfully, but these errors were encountered: