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
including a module with no values still requires that it have a .ml file #5354
Comments
Comment author: @gasche Note that you could also write a .ml with no values, and use Deriving a signature from an implementation (module type of ...) is well-defined. Deriving an implementation from a signature is not, in the general case; we can do it in the case where it only exports types/signatures, but I'm not sure it's a good idea to add a special case here. Besides, as implementations can have side-effects, there are a lot of observably-different implementations of an interface, even when it doesn't export any value, none of them more "general" than the other. |
Comment author: @garrigue Actually you can create a module from a signature. module rec A' : module type of A = A' Note that you may need some "with" declarations if you want to keep the sharing with A. |
Comment author: turpin My one-page-long answer just disappeared because of a Mantis timeout. I give up. |
Comment author: @gasche Jacques, indeed, that's tricky, and it's the second time you catch me with this! As you trick shows, however, my first comment was misguided: we are not in the situation where we want to get a module from a signature, 'A' in the source code explicitly refers to a module A (whose signature is described in a.mli). Even if we considered adding an operation "module of " that would generate an empty implementation of type-only signatures, we would here have to write "module of (module type of A)". This is clearly nonsensical. turpin, I really think the problem is in the choice you made of having a .mli with no .ml, instead of a .ml with no .mli. Writing .mli only is useful to defer the choice of the concrete implementation (the .cmo passed at linking time may come from somewhere else), but is not meant to provide implementations. If you want to define a module with only type components, writing a .ml only is the right way to do, it seems. I'm therefore moving to "resolve" the ticket as "no change required". Feel free to add more explanations if you think turning the .mli into a .ml does not solve your problem. |
Comment author: pilki @gasche: I don't agree when you say that "the right way" is to just write a .ml file! It seems reasonable to me to expect to be able to write a library and have its user only read the .mli files (because people should care about the interface, not the implementation). Therefore you have to write a .mli file with your types and the related comments. And you can't just write a ml file and have the mli generated with ocamlc -i since you would lose the comments. I'm not saying the issue should be "fixed" (there is always the option of cp blah.mli blah.ml...), just that your solution is not the right one :) |
Comment author: @gasche You can name your file "foo.mli" and compile it with |
Original bug ID: 5354
Reporter: turpin
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2013-08-31T10:44:04Z)
Resolution: not a bug
Priority: normal
Severity: tweak
Version: 3.12.1
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @gasche @protz
Bug description
If I have a.mli (with no values) without a.ml, then I am not allow to write "include A" in b.ml, for example (I get a "reference to undefined global A" error while linking.
The text was updated successfully, but these errors were encountered: