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

Recursive signatures #6818

Closed
vicuna opened this issue Mar 23, 2015 · 3 comments
Closed

Recursive signatures #6818

vicuna opened this issue Mar 23, 2015 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Mar 23, 2015

Original bug ID: 6818
Reporter: @yallop
Status: acknowledged (set by @damiendoligez on 2015-06-15T15:07:29Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing
Related to: #4899
Monitored by: runhang

Bug description

It would be useful to have support for recursive signatures. The most common need is in code involving first-class modules, where I'd like to write

   module type rec R =
   sig
     val f : (module R) -> unit
   end

Of course, there's a workaround, but it's rather clunky:

   module rec R :
   sig
      module type T =
      sig
        val f: (module R.T) -> unit
      end
   end = R

Now that we have both recursive and non-recursive type bindings it would be more uniform to also support both recursive and non-recursive module type bindings.

@vicuna
Copy link
Author

vicuna commented Mar 23, 2015

Comment author: @yallop

PR #4899 is similar, but suggests changing the semantics of the existing 'module type' construct to support recursion. As Jacques said, that's not a workable approach, since it breaks backwards compatibility. The approach I'm proposing here -- adding an optional 'rec' -- is entirely backwards compatible.

@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
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

3 participants