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

Syntax for re-exporting constructors / fields #7025

Closed
vicuna opened this issue Oct 19, 2015 · 7 comments
Closed

Syntax for re-exporting constructors / fields #7025

vicuna opened this issue Oct 19, 2015 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Oct 19, 2015

Original bug ID: 7025
Reporter: @ppedrot
Status: acknowledged (set by @damiendoligez on 2017-03-01T10:19:24Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.3
Category: language features
Monitored by: @gasche @diml @yallop @hcarty

Bug description

It would be nice to have a concise syntax to export the constructors and fields of already declared datatypes. It is already possible to do so as follows:

type foo = Foo.foo =
| Foo1
| Foo2 of int

type bar = Bar.bar = { bar : int }

Yet, this has some drawbacks. It is indeed tedious and error-prone because one needs to maintain the definition of the type in various places. In addition, this forces to redeclare a type, even if this is just an alias.

It would be nice just to be able to write something along the lines of:

open Foo.foo

with the effect that all constructors and fields are exported in the current environment.

@vicuna
Copy link
Author

vicuna commented Oct 19, 2015

Comment author: @gasche

Do you have a nice example of where/how you use re-export and would benefit from this feature?

@vicuna
Copy link
Author

vicuna commented Oct 19, 2015

Comment author: @ppedrot

We use this pattern in Coq for compatibility layers. For instance, the "kind_of_term" type in Term is reexported from Constr:

https://github.com/coq/coq/blob/trunk/kernel/term.mli

But you do not want to open the whole Constr module because there are short names in there that may conflict one with another.

More generally, this kind of pattern appears when using modules to fully qualify names (i.e. "Foo.bar" instead of a toplevel "open Foo" followed by uses of "foo_bar"). In that case you still want to access the unqualified names of the constructors without importing everything else.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2015

Comment author: @alainfrisch

According to the example you provide, it seems that what you want is really to "include" a type definition, not "open its constructors/fields". FWIW, we have also many similar occurrences, for the same purpose (creating "compatibility layers"). I'd suggest to use a syntax such as:

include type Foo.t

because this is very similar to including a module (type).

@vicuna
Copy link
Author

vicuna commented Oct 20, 2015

Comment author: @ppedrot

@Frisch: that's true, even though both an include and an open make sense.

"open Foo.t" would make the constructors of Foo.t available in the scope with their short name, while "include Foo.t" would reexport the constructors of Foo.t in a module / module type.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2015

Comment author: @lpw25

I think these would only make sense if we also allowed paths like "Foo.foo.Foo1", which has been suggested on a number of occasions -- most recently as part of the inline record discussion.

@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
@gasche gasche removed the Stale label May 18, 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