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

A program using recursive modules doesn't compile since 3.10 #4993

Open
vicuna opened this issue Mar 5, 2010 · 8 comments
Open

A program using recursive modules doesn't compile since 3.10 #4993

vicuna opened this issue Mar 5, 2010 · 8 comments

Comments

@vicuna
Copy link

vicuna commented Mar 5, 2010

Original bug ID: 4993
Reporter: @garrigue
Assigned to: @garrigue
Status: assigned (set by @mshinwell on 2016-12-07T13:15:28Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.2
Target version: later
Category: typing
Tags: recmod
Monitored by: "Julien Signoles" @Chris00

Bug description

The attached program did compile with ocaml 3.09.3,
but doesn't compile with all versions since 3.10.0.

Note that other versions of the same program using
polymorphic variants (and avoiding conversions) do
still work.

File attachments

@vicuna
Copy link
Author

vicuna commented Apr 30, 2010

Comment author: @garrigue

I should have mentioned that this program is particularly important, as it demonstrated the
power of ocaml recursive modules by encoding the expression problem without using
polymorphic variants. This was presented at IFIP WG2.8 in 2005.
So this is is kind of unfortunate that this doesn't work anymore.
On the other hand, I understand that recursive modules were not a finished feature at that time,
so maybe I was just lucky.

@vicuna
Copy link
Author

vicuna commented May 4, 2010

Comment author: @xavierleroy

Jacques, I know this code is dear to your heart :-) The typechecking of recursive modules was unsound in 3.09, and what I think are the correct typing rules could not be implemented because they give rise to cycles of type abbreviations that cause the typechecker to loop. So, what's implemented today is a conservative approximation, and I'm not surprised it rejects some useful codes. At any rate, I learnt one thing the hard way: recursive modules will never be 100% right until the type-checker is resistant to cyclic abbreviations (treating them as abstract types instead of stupidly looping).

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

Jacques, can this issue be closed?

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @garrigue

I'd prefer to keep it: ideally this should work some day.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 18, 2020
@garrigue
Copy link
Contributor

Still dreaming it could come back...

@github-actions github-actions bot removed the Stale label Jun 24, 2020
@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label Jul 21, 2021
@garrigue garrigue removed the Stale label Jul 21, 2021
@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label Aug 10, 2022
@garrigue garrigue removed the Stale label Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants