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

approx_type ignores structural types #6478

Closed
vicuna opened this issue Jul 5, 2014 · 6 comments
Closed

approx_type ignores structural types #6478

vicuna opened this issue Jul 5, 2014 · 6 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Jul 5, 2014

Original bug ID: 6478
Reporter: @lpw25
Assigned to: @garrigue
Status: confirmed (set by @garrigue on 2014-07-06T00:59:24Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.0+dev
Category: typing
Monitored by: @gasche

Bug description

approx_type (which approximates the type of a constraint in a recursive definition) does not handle structural types. This can lead to some surprising behaviour, since using an alias of a structural type does work.

For example:

Process ocaml-toplevel finished
        OCaml version 4.03.0+dev0-2014-05-12

# #warnings "-10";;

# let k = object method m : 'a. 'a -> 'a = fun x -> x end;;
val k : < m : 'a. 'a -> 'a > = <obj>

# let rec x =
    lazy (x#m ());
    lazy (x#m "hello");
    (k : < m : 'a. 'a -> 'a >);;
      Characters 45-52:
      lazy (x#m "hello");
                ^^^^^^^
Error: This expression has type string but an expression was expected of type
         unit

# type t = < m : 'a. 'a -> 'a >;;
type t = < m : 'a. 'a -> 'a >

# let rec x =
    lazy (x#m ());
    lazy (x#m "hello");
    (k : t);;
      val x : t = <obj>

Ideally, the constraints in recursive definitions would be properly typed during approximation, although I assume there is some reason this is not already the case.

Even if there is a good reason this cannot be done, it is potentially confusing, so I thought it was worth creating an issue for.

@vicuna
Copy link
Author

vicuna commented Jul 6, 2014

Comment author: @garrigue

Indeed, there is something wrong here.
I don't know why approx_type handles named types to start with: originally it was intended for labels and optional arguments.

@vicuna
Copy link
Author

vicuna commented Sep 14, 2014

Comment author: @damiendoligez

I may be totally wrong, but I seem to remember that approx_type was extended to get better type errors for let rec.

[edit: IIRC it was extended by Alain]

@vicuna
Copy link
Author

vicuna commented Apr 6, 2016

Comment author: @alainfrisch

After a quick look at the history, it seems that the only changes I did on Typecore.approx_type were related to changes in the definition of the Parsetree (no changes on the behavior).

@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 11, 2020
@garrigue
Copy link
Contributor

Probably worth having another look at it.

@github-actions github-actions bot removed the Stale label Jun 15, 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.

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