0005354: including a module with no values still requires that it have a .ml file

Notes
(0006477) gasche (developer) 2011-12-21 22:46	Note that you could also write a .ml with no values, and use `module type of M` in signature posititions. Would this suit your need? 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.

(0006481) garrigue (manager) 2011-12-22 01:48	Actually you can create a module from a signature. module rec A' : module type of A = A' include A' Note that you may need some "with" declarations if you want to keep the sharing with A.

(0006491) turpin (reporter) 2011-12-22 10:54	My one-page-long answer just disappeared because of a Mantis timeout. I give up.

(0006524) gasche (developer) 2011-12-23 18:24	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 <sig>" 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.

(0006536) pilki (reporter) 2011-12-24 16:03	@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 :)

(0006537) gasche (developer) 2011-12-24 19:48	You can name your file "foo.mli" and compile it with ocamlc foo.mli ocamlc -c -impl foo.mli if that is your fancy. If there is no .mli, it seems reasonable to assume that the user will read the .ml instead... or the ocamldoc generation that you can equally well generate from a .ml

Issue History
Date Modified	Username	Field	Change
2011-09-01 17:22	turpin	New Issue
2011-12-21 22:46	gasche	Note Added: 0006477
2011-12-21 22:47	gasche	Status	new => feedback
2011-12-22 01:48	garrigue	Note Added: 0006481
2011-12-22 10:54	turpin	Note Added: 0006491
2011-12-22 10:54	turpin	Status	feedback => new
2011-12-23 18:24	gasche	Note Added: 0006524
2011-12-23 18:24	gasche	Status	new => resolved
2011-12-23 18:24	gasche	Resolution	open => no change required
2011-12-23 18:24	gasche	Assigned To	=> gasche
2011-12-24 16:03	pilki	Note Added: 0006536
2011-12-24 19:48	gasche	Note Added: 0006537

Relationships