Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007364OCamltypingpublic2016-09-21 23:452018-12-11 20:38
Reportergasche 
Assigned Todoligez 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version4.04.0 +dev / +beta1 / +beta2 
Target VersionFixed in Version 
Summary0007364: Inflexibility of unboxed types in recursive declarations
DescriptionMarkus Mottl remarked that unboxed types safeguards against floating points are not computed precisely enough in the case of mutually recursive type declarations:

  https://github.com/ocaml/ocaml/pull/606#issuecomment-248656482 [^]

His example is natural, it suggests that fixing this limitation before the release could be very beneficial.
Steps To Reproducetype ('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
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0007532resolvedgasche The compiler does not unbox a type which can not contain a float value 
has duplicate 0007774resolvedgasche Rejected [@@unboxed] on a GADT in a mutual definition with a polymorphic type constructor 

-  Notes
(0016316)
frisch (developer)
2016-09-22 00:55
edited on: 2016-09-22 00:55

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.

(0016446)
doligez (administrator)
2016-10-26 14:53

I agree with Alain. This probably needs a fixpoint computation on type declarations, which I won't do in a hurry.
(0016447)
gasche (administrator)
2016-10-26 16:16

Ok, I updated the Changelog to emphasize this limitation.
(0017417)
gasche (administrator)
2017-02-23 18:06

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.
(0018572)
xleroy (administrator)
2017-10-15 16:43

> 1. Give Gabriel a permanent research position.

Achievement unlocked!
(0018711)
gasche (administrator)
2017-11-29 09:57

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.)
(0019031)
gasche (administrator)
2018-04-14 23:16

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.
(0019502)
gasche (administrator)
2018-12-11 20:38

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

  https://github.com/ocaml/ocaml/pull/2188 [^]

- Issue History
Date Modified Username Field Change
2016-09-21 23:45 gasche New Issue
2016-09-21 23:46 gasche Status new => confirmed
2016-09-22 00:55 frisch Note Added: 0016316
2016-09-22 00:55 frisch Note Edited: 0016316 View Revisions
2016-10-26 14:53 doligez Note Added: 0016446
2016-10-26 14:53 doligez Target Version 4.04.0 +dev / +beta1 / +beta2 => 4.05.0 +dev/beta1/beta2/beta3/rc1
2016-10-26 16:16 gasche Note Added: 0016447
2016-12-07 17:54 shinwell Assigned To => doligez
2016-12-07 17:54 shinwell Status confirmed => assigned
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-02-23 17:06 doligez Category -OCaml general => typing
2017-02-23 17:06 doligez Target Version 4.05.0 +dev/beta1/beta2/beta3/rc1 =>
2017-02-23 18:06 gasche Note Added: 0017417
2017-05-11 19:56 gasche Relationship added has duplicate 0007532
2017-10-15 16:43 xleroy Note Added: 0018572
2017-11-29 09:57 gasche Note Added: 0018711
2018-04-14 23:13 gasche Relationship added has duplicate 0007774
2018-04-14 23:16 gasche Note Added: 0019031
2018-12-11 20:38 gasche Note Added: 0019502


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker