Gabriel Scherer

I'm curious about the current status of the project. Any news?

Thanks for the news. One side-effect benefit I hoped for this project is to get a usable `ocamlnat` toplevel (installed) for all users (I assume that this means upstreaming the...

My understanding is that currently the project is on hold. @dra27 took care of upstreaming the necessary hooks to be able to implement a JIT outside the compiler, which is...

The way I think of it, constructors `type foo = ... | Bar of bar` denote an embedding of `bar` into `foo` that gives distinguishability (from other constructors) -- initiality...

Thinking more about this as well: - I like the general idea of the proposal, and I think that being able to write `type zarith = Small of int [@@unboxed]...

- When we do inlining, I would prefer if we manually specified the representations of the constructors, instead of letting the compiler perform an implicit transformation. The unboxing step itself...

@chambart : two answer two of your questions - I propose to avoid implicit transformations where the compiler "finds a representation such as X", but instead favor explicit annotations that...

In a sense the point is that if a given compiler pass makes choices based on assumptions on runtime value representations, then only OCaml implementations that satisfy those assumptions can...

My understanding is that the part of the build that would need to be duplicated (parsing, type-checking and bytecode compilation) takes only a fraction of the time, compared to either...

Of course this could be reduced further by, say, having an intermediate output for the typedtree, so that all three builds (.cmx, .cmo, .js) could reuse it. Then the build...