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
Comments
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. |
Comment author: @damiendoligez I agree with Alain. This probably needs a fixpoint computation on type declarations, which I won't do in a hurry. |
Comment author: @gasche Ok, I updated the Changelog to emphasize this limitation. |
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:
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. |
Comment author: @xavierleroy
Achievement unlocked! |
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.) |
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 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. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I think that @rlepigre, @gasche and @SimonColin have thoroughly fixed this in #2188, which is now merged. The code in the bug report is now accepted in
|
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
The text was updated successfully, but these errors were encountered: