Navigation Menu

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

Give multiple interfaces (internal/external) to one compilation unit of a library #6823

Closed
vicuna opened this issue Mar 26, 2015 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Mar 26, 2015

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.

@vicuna
Copy link
Author

vicuna commented Mar 26, 2015

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 internal/a.ml internal/a.mli external/a.mli with external/a.mli included in internal/a.mli

ocamlc -o internal/a.cmi internal/a.mli
ocamlc -o internal/a.cmo internal/a.ml

ocamlsig -o external/a.cmi internal/a.cmi external/a.mli

install external/a.cmi internal/a.cmo

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

@vicuna
Copy link
Author

vicuna commented Mar 27, 2015

Comment author: @garrigue

What you should do is just create an export version of your module:

mylib_a.ml:
include Mylib_intern_a

mylib_a.mli:
type t = Mylib_intern_a.t

And do not export mylib_intern_a.cmi

Of course the dangling type names are not very nice, but this is not a new.

@vicuna
Copy link
Author

vicuna commented Apr 3, 2015

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:

  • It would be handy to have an option for ocamlc/opt that it should use the current .cmi even if there is no .mli. From one .mli we would create two .cmi` using a ppx for filtering the declaration (I think there is also such request for parallelism). If you think the idea is acceptable, I can do the merge request.

  • with -no-short-path you have in the library user type errors:

Mylib_a.t = Mylib_intern_a.t

but who doesn't use short-path?

@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

1 participant