Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[@@unboxed] for single-constructor, single-field GADT introducing existential type #7597
Original bug ID: 7597
[@@unboxed] looked like a great feature, but very often I can't use it because of abstract types. Here is my ml file for a minimal example:
type _ para = C
That's great, but when I want to hide the definition of _ para in the mli, i.e.
type _ para
...I get rejected.
I've tried hard to understand the discussion #3007.
It seems that my mli is rejected because there is a danger that my abstract type might be an float? (or is it an unboxed float that would be dangerous?).
Again, I don't care much about floats here and I don't use them in my project, whether boxed or unboxed :-) So it seems desirable to me that the issue of floats doesn't pollute the otherwise great feature of not boxing a single-constructor, single-field GADT introducing an existential type.
type _ para [@@non_float]
as suggested in #3007 following the remark
Is there currently a workaround that I have missed?
Comment author: @yallop
In OCaml the functions that construct arrays check whether their arguments are represented as floats, and use a different (unboxed) array representation if they are. For that reason it's not safe to give float values and non-float values the same type. Here's an example of what happens if you do:
Here the array constructor determines that the first argument is a float, so it tries to unbox the second argument as a float, too.
Your example is similar. With the following definitions,
the type 'para' might be defined as follows:
Then, in the following code, both array elements would have the same type, but the first would have float representation, so the array constructor would try to unbox the second (non-float) argument as a float:
[| H 0.0; H 0 |]