Separability axis basics

[dkalinichenko-js]

Add the separability jkind axis. Separability is a shallow, non-modal axis going non_float < separable < non_separable, with non_float denoting types whose values are not pointers to Double_tag blocks, separable denoting types with either all values being pointers to Double_tag blocks or none, and non_separable denoting all types.

Add jkinds non_float_value, for non-float values, and immutable_separable_value, for floats. I'm not sold on the second jkind and will likely drop it from the final version of this PR.

Change other jkinds to non_float or separable where appropriate. In particular, default immutable_data to non_float. This will exclude floats from immutable_data, but will mark records, variants and other immutable_data types as non_float. Since immutable_data almost always appears in a covariant positions, this seems like the best choice.

Separability is a shallow axis, so it should not affect with-bounds. Semantics of separability for product layouts are to be determined, but it seems like all products should be non-float?

('a : non_float_value) or_null will be made non_float in a future PR.

t : non_separable_value will provide an escape hatch from existing OCaml separability checks (e.g. for existential) in a future PR. Those checks will also themselves take into account separability annotations.

any_non_null will be changed to any_separable, with arrays accepting any_separable elements, in a future PR.

[goldfirere]

Nice design write-up. For these comments, I have not looked at all at the implementation — just working through consequences of the design.

Should int64# be non-separable? After all, the type contains both pointers to heap-allocated floats, among other values. According to your definition, it probably should be non-separable, but my guess is that this would cause trouble. We could modify the definition to exclude non-values, and that would fix this little problem. But it also suggests we should never query the separability of non-values in the implementation. (I think this last sentence would be true without effort.)

So I continue to wonder about making separability a part of the value layout somehow. What currently happens with unboxed products of floats in arrays? My guess is that the constructing function for arrays does not do the float-check for non-values. This means that we could get an array full of heap-allocated floats by storing an unboxed product floats…. but my guess is that this is just fine. All that said, I’m not against going ahead with the design here: it’s probably easier to implement than making value more interesting. But maybe we should briefly discuss alternatives today.

[dkalinichenko-js]

Note on mod bounds for immutable_data: we may rename immutable_data to plain_data or simple_data in a subsequent PR for more clarity.

[goldfirere]

Looks good! Sorry this took so long to review.

[goldfirere]

Reviewed most recent commit

[goldfirere]

Small plea: unless there's a good reason, could you avoid rebasing while a patch is under active review? GitHub lacks a mechanism for me to know which commits I've reviewed and which I haven't, and rebasing clobbers the timeline (which would otherwise be such an indication). If/when rebasing is necessary, then it's helpful for commit messages to have some variability, just to use as identifiers (of course, rebasing changes the hash, so we need something to identify the commit). It can just be a little keyboard smash for all I care, but it gives a way of tracking commits across rebases. :) Thanks!

[dkalinichenko-js]

Ack, sorry! I usually rebase when going back to the feature to avoid another review cycle for fixes due to the rebase, but I didn't consider the effect on your review.

I think GitHub can track which commits you reviewed though? At least I recall it keep tracking the new additions for me when I'm reviewing PRs. Maybe rebase breaks that?

[goldfirere]

Yes rebase breaks that. GitHub also tracks files that I've seen, but at a per-file granularity, which is only marginally useful.

(Rebasing the way you have does make sense! It's just too bad that GitHub doesn't accommodate that good workflow so well.)