Conference Presentation
Unboxed Types for OCaml
- Code examples will soon shift from currently functional prototypes to features supported only on internal OCaml branches, with the connection to production reality expected to become increasingly tenuous.
- Implementation of
hash_in64and similar features relies on prototypes that are only half-implemented or exist solely in internal branches, with full standard library availability anticipated to take a while. - Future development plans include eventually integrating polymorphism for expressing multiple code versions, a goal described as being a long way off, and incorporating a three-year-old patch for new array types which faces delays due to necessary compiler changes.
- The roadmap foresees the introduction of explicit syntax for converting between different representations (e.g., point and hash point), as automatic conversion for boxed and unboxed versions is not planned.
- Design constraints for unboxed sums remain unsettled, with likely restrictions on allowed types and unresolved questions regarding the handling of mixed raw data and garbage-collected pointers.
- A preference exists to avoid formalizing the "float array hack" to prevent prolonging its lifecycle, while mixed pointer and non-pointer type restrictions currently mirror existing garbage collector behavior.
- The compiler is predicted to ignore the current prototype's limitations and generate code as if fully annotated once the type-checking prototype is complete, despite the prototype not currently generating optimized code.
- Targeting backends requiring 64-bit types split into 32-bit registers does not necessitate conditional compilation, as the OCaml backend already handles this; however, linking code compiled in fast and slow modes will not work.
- Whole-program compilation via Milton is available as an alternative if separate compilation is not required, though the speaker notes that significant work remains before benchmarking can occur.
- Kind checks are expected to require surprisingly little compiler work and are not inherently slower, though they have neither been benchmarked nor seriously optimized.
- Accessing deep fields in nested records requires attention to avoid copying large data volumes, but optimization can likely discard unused loads without needing complex borrowing mechanisms akin to Rust.
- The speaker anticipates that the remaining design choices for the type system are largely unsettled, with many restrictions and implementation details yet to be fully explored.