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
Give multiple interfaces (internal/external) to one compilation unit of a library #6823
Comments
Comment author: bobot One possible way would be to add the ability to create a .cmi from a .cmi and a .mli which is included in the signature of the given .cmi. Given the files
Internally internal/a.cmi is used but the user of the library use external/a.cmi. PS: We can play with attributes in order to "create" external/a.mli from internal/a.mli |
Comment author: @garrigue What you should do is just create an export version of your module: mylib_a.ml: mylib_a.mli: And do not export mylib_intern_a.cmi Of course the dangling type names are not very nice, but this is not a new. |
Comment author: bobot Thank you, that simply works! It will need some plumbing (module-alias, -open, a ppx that filter the signature) for making that transparent to the library user and the developer, but indeed it can work, it is not too complicated and it requires no modification of ocaml! Except that:
but who doesn't use short-path? |
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. |
Original bug ID: 6823
Reporter: bobot
Status: acknowledged (set by @damiendoligez on 2015-06-15T15:15:14Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.1
Category: typing
Monitored by: @diml @ygrek @yakobowski
Bug description
Module alias and some other 4.02.0 new features created a path for namespaces away from pack. However if one wants to hide to the user of the library some parts of some compilations unit it must give to the "root" module (the one that have the name of the library and that contains module aliases) a signature. By doing so all the module (at least the one coerced) must be linked, so you loose the advantage of the module alias.
How could a compilation unit export some functions to the other compilation unit of the library but hide them for the user of the library?
Steps to reproduce
If a cmi of a compilation unit is not installed, it is completely hidden for the user. But this technique doesn't allow to hide part of a module.
The text was updated successfully, but these errors were encountered: