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

Destructive substitution on classes produces unrepresentable module type #6654

Closed
vicuna opened this issue Nov 10, 2014 · 7 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Nov 10, 2014

Original bug ID: 6654
Reporter: @lpw25
Status: confirmed (set by @damiendoligez on 2015-01-07T18:57:14Z)
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: typing
Related to: #4791
Monitored by: @hcarty

Bug description

If you apply destructive substitution to a class or class type the type system handles it correctly, but the resulting module type cannot be represented by OCaml's syntax:

# module type S = sig
    class c : object method
    m : int end
  end;;
module type S = sig class c : object method m : int end end

# class d = object method m = 3 end;;
class d : object method m : int end

# module type T = S with type c := d;;
module type T =
  sig
    class c : object method m : int end
    class type c = object method m : int end
    type #c = #d
  end
@vicuna
Copy link
Author

vicuna commented Mar 14, 2017

Comment author: @garrigue

Yet another example of signature that cannot be parsed/typed.
Of course we could forbid it, but would it help?
Another solution would be to allow destructive substitution for all declaration, but this is harder.
For the time being, doing nothing seems reasonable.

@yallop
Copy link
Member

yallop commented Apr 8, 2019

This issue has turned into a bug in trunk. The final line now fails with an internal Invalid_argument exception:

# module type S = sig
    class c : object method
    m : int end
  end;;
      module type S = sig class c : object method m : int end end
# class d = object method m = 3 end;;
class d : object method m : int end
# module type T = S with type c := d;;
Fatal error: exception Invalid_argument("split_at")

@yallop yallop added the bug label Apr 8, 2019
@gasche
Copy link
Member

gasche commented Apr 8, 2019

This suggests that maybe we should be more proactive in adding examples for known issues in the testsuite, so that we notice when the behavior changes (in good or bad ways).

@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 garrigue removed the Stale label May 11, 2020
@garrigue
Copy link
Contributor

There is a real bug now. Appeared in 4.08.

@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
@Octachron
Copy link
Member

Fixed in 4.13 by #10401 : with constraint cannot alter the type associated to a class anymore, and

# module type T = S with type c := d;;

now fails with

Error: The signature constrained by `with' has no component named c

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

5 participants