Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inflexibility of unboxed types in recursive declarations #7364

Open
vicuna opened this issue Sep 21, 2016 · 8 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented Sep 21, 2016

Original bug ID: 7364
Reporter: @gasche
Assigned to: @damiendoligez
Status: assigned (set by @mshinwell on 2016-12-07T16:54:05Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.04.0 +dev / +beta1 / +beta2
Category: typing
Has duplicate: #7532 #7774
Monitored by: sweeks @yallop

Bug description

Markus Mottl remarked that unboxed types safeguards against floating points are not computed precisely enough in the case of mutually recursive type declarations:

#606 (comment)

His example is natural, it suggests that fixing this limitation before the release could be very beneficial.

Steps to reproduce

type ('a, 'kind) tree =
| Root : { mutable value : 'a; mutable rank : int } -> ('a, [ root ]) tree | Inner : { mutable parent : 'a node } -> ('a, [ inner ]) tree

and 'a node = Node : ('a, _) tree -> 'a node [@@ocaml.unboxed]

type 'a t = ('a, [ `inner ]) tree

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 21, 2016

Comment author: @alainfrisch

The criterion to decide float/non-float is not really specified, and there will certainly be other similar cases (e.g. with recursive modules). This can be improved over time (e.g. by dropping the unboxed float array hack?), but doing it in a rush so close from the release date does not seem a good idea to me, especially considering that the current implementation for the criterion is already quite complex.

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 26, 2016

Comment author: @damiendoligez

I agree with Alain. This probably needs a fixpoint computation on type declarations, which I won't do in a hurry.

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 26, 2016

Comment author: @gasche

Ok, I updated the Changelog to emphasize this limitation.

@vicuna

This comment has been minimized.

Copy link
Author

commented Feb 23, 2017

Comment author: @gasche

I believe that this is a fairly problematic restriction to the feature, in the sense that it does not make sense from a language design point of view. I understand that it is not on anyone's high-priority list, but by the time it gets pushed to such a list it will be too late, your users will be relying on the feature and want to support OCaml versions that are broken in this way, so people will design ugly work-around.

Is there an actual step we can take to make sure that this is at least ready for 4.06? I have three ideas:

  1. Give Gabriel a permanent research position.
  2. Entice Jeremy Yallop into solving the problem.
  3. Find a student/hobbyist with free time that would be willing to work on a demanding-work, moderate-risk, nice-reward programming task for the OCaml compiler.

If we decide to go for (3), I can write a project description (I think that it would be around two months of work for someone not super-familiar with the codebase, if we include the integration time), and publicize the demand on the caml-list for example.

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 15, 2017

Comment author: @xavierleroy

  1. Give Gabriel a permanent research position.

Achievement unlocked!

@vicuna

This comment has been minimized.

Copy link
Author

commented Nov 29, 2017

Comment author: @gasche

So I'm currently advising a student intern (Simon Colin) working on precisely this issue (better understanding the [@@unboxed] safety check, and extending it to mutually-recursive definitions), and I hope that he will have something to show around January/February.

(If someone else wants to work on this before that time, please get in touch with me first.)

@vicuna

This comment has been minimized.

Copy link
Author

commented Apr 14, 2018

Comment author: @gasche

Rodolphe has a simpler (but less well-justified) example of overly restrictive behavior of the current implementation:

type 'a t = {name : string; data : 'a}
and any = Any : 'a t -> any [@@ocaml.unboxed]

and I gave a link in its duplicate MPR to Simon's github repository:

https://github.com/SimonColin/ocaml-unboxed-check-project

Basically the current status is that the researchy part is done, but there is no compiler patch yet. I was hoping to write it together with Simon, but if that doesn't work out I'll try to write it in time for 4.08.

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 11, 2018

Comment author: @gasche

With Rodolphe Lepigre, we implemented Simon's internship as a Pull Request:

#2188

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.