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

ocamlc -i produces incorrect result #4791

Closed
vicuna opened this issue May 15, 2009 · 7 comments
Closed

ocamlc -i produces incorrect result #4791

vicuna opened this issue May 15, 2009 · 7 comments

Comments

@vicuna
Copy link

vicuna commented May 15, 2009

Original bug ID: 4791
Reporter: jerhoud
Status: acknowledged (set by @damiendoligez on 2009-05-15T15:09:02Z)
Resolution: open
Priority: low
Severity: feature
Version: 3.10.2
Target version: later
Category: typing
Has duplicate: #6323 #7402
Related to: #6416 #6634 #6654 #7458
Parent of: #6587

Bug description

cat a.ml

(* begin of a.ml *)
type t = A

module B =
struct
type t = B

let f A = B
end
(* end of a.ml *)

ocamlc -i a.ml

type t = A
module B : sig type t = B val f : t -> t end

The type of f is incorrect, it should be something like "val f : A.t -> B.t" except that there seems to be no way of actually writing a correct signature for module B (both A.t and B.t are unbound at this stage).

On the other hand, other definitions using f seem to be typed correctly.

I may admit that there is no way to solve this problem, but ocamlc -i should report an error instead of producing an incorrect result.

File attachments

@vicuna
Copy link
Author

vicuna commented Jun 1, 2012

Comment author: @garrigue

Scoping of types in signatures is unfortunately a problem with no easy solution.
This is just one of its instances.

Note that unification errors involving several types with the same name result in printing internal ids to distinguish them.

@vicuna
Copy link
Author

vicuna commented Jul 31, 2014

Comment author: @damiendoligez

FTR, there is one radical solution to this problem: refuse any value whose type cannot be expressed in the current scope. In this example, ocamlc would refuse to compile a.ml, with or without option -i.

@vicuna
Copy link
Author

vicuna commented Mar 14, 2017

Comment author: @garrigue

No good general solution as there could be very strange scoping situations, one just has to fix the signature by hand when possible.

@vicuna
Copy link
Author

vicuna commented Mar 23, 2017

Comment author: @Octachron

If printing the correct signature in the general case does seem quite complex, I think that adding a warning for unprintable signature might be worthwhile, see #1120 for a possible implementation.

@vicuna
Copy link
Author

vicuna commented Jun 26, 2018

Comment author: @Octachron

With the PR above merged, ocamlc -i a.ml produces a warning:

Warning 63: The printed interface differs from the inferred interface.
The inferred interface contained items which could not be printed
properly due to name collisions between identifiers.
File "a.ml", line 5, characters 2-12:
Definition of type t/1
File "a.ml", line 1, characters 0-10:
Definition of type t/2
Beware that this warning is purely informational and will not catch
all instances of erroneous printed interface.
type t = A
module B : sig type t = B val f : t/2 -> t/1 end

@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
@nojb
Copy link
Contributor

nojb commented May 18, 2020

Comment by @garrigue above says that a general solution unlikely (if not impossible), and a mitigation warning was merged in #1120, so closing.

@nojb nojb closed this as completed May 18, 2020
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

2 participants