Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005354OCamlOCaml generalpublic2011-09-01 17:222013-08-31 12:44
Reporterturpin 
Assigned Togasche 
PrioritynormalSeveritytweakReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version3.12.1 
Target VersionFixed in Version 
Summary0005354: including a module with no values still requires that it have a .ml file
DescriptionIf 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.

TagsNo tags attached.
Attached Files

- Relationships

-  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
2013-08-31 12:44 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker