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

Update mode for inferring mli files #5777

Closed
vicuna opened this issue Oct 7, 2012 · 5 comments
Closed

Update mode for inferring mli files #5777

vicuna opened this issue Oct 7, 2012 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Oct 7, 2012

Original bug ID: 5777
Reporter: meyer
Status: closed (set by @mshinwell on 2016-12-12T15:50:06Z)
Resolution: won't fix
Priority: normal
Severity: feature
Version: 4.00.1
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @glondu @hcarty

Bug description

Some people reported that they want selectively infer signatures for specific entries - value or types by annotating them in some way in the ml file. (e.g #5764)

I'm proposing completely different solution.

If somebody specifies something like:

ocamlc -infer-update foo.ml

when the mli is not present it will create with all the entries like normally -i would normally print. Otherwise it will re-parse the mli file, compare if the signatures change with some specific rules, and then replace these entries but only with the new ones.

@vicuna
Copy link
Author

vicuna commented Oct 30, 2012

Comment author: Bardou

What about the following example:

type t = int
let f x = x + 1

interface:

type t
val f: t -> int

I now change implementation as follows:

type t = float
let f x = x +. 1.

The inferred type for f is float -> float. How should the .mli be updated? I would like:

val f: t -> float

But it does not seem easy to decide that we want to keep t.

@vicuna
Copy link
Author

vicuna commented Oct 30, 2012

Comment author: @alainfrisch

I really don't like the idea that the compiler would parse some source file, modify it, and save it back. I've nothing against an external tool trying to do it properly (preserving the formatting and comments of the original file), but I don't think this is robust enough for a compiler and that we should encourage this workflow.

@vicuna
Copy link
Author

vicuna commented Oct 31, 2012

Comment author: @bobzhang

frisch, I agree with you, how about my proposal?

@vicuna
Copy link
Author

vicuna commented Oct 31, 2012

Comment author: @alainfrisch

how about my proposal?

Do you mean the "private" syntax proposed in #5764?

I don't have a strong opinion on the subject. For me, having to write the .mli file is not a problem. But it makes sense to have a way to define a structure item for the rest of the module but hide it automatically from the resulting signature.

@vicuna
Copy link
Author

vicuna commented Dec 12, 2016

Comment author: @mshinwell

This proposal does not appear to have been well-received in 2012. I move to close this issue.

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

1 participant