]> On Thu, 2003-11-20 at 04:43, Brian Hurt wrote: > 2) introduce a new keyword 'private'. Everything except those types and > values marked private is exported. > > Note that we're breaking working code here. I do not see how, except that the keyword private is already used :-) I suggested previously a third keyword would be useful, 'abstract' which is used like: abstract type x = y; which generates the interface type x; I think this is called "limited private" in Ada? This does not break anything (apart from stealing some identifiers as keywords). The assumption is that there is only an .ml file, no .mli file: if you don't use private or abstract keyword, the result is the same as it is now. If you do, you're using an extension which is not well formed syntactically at present, and so no existing code can be broken. The only real difficulty here is: "what if there is an .mli file that disagrees with the .ml file?" This can already happen: a constraint on a function type, or a function that isn't in the interface at all. But what if a function is marked private in the ml file but exists in the .mli file, implying public? I guess the best answer is: its an error. [Same if a type is marked abstract] As a matter of interest it may be that the following is useful in an interface: abstract type x = int; and what that means is: the typing is type x; BUT the compiler may use the 'secret' knowledge it's actually an int for optimisation. Something similar to this already happens for classes: you have to give implementation details (data members of a class) in mli files: they're ignored by the typing I think, but needed for code generation The mechanism being discussed here may make it possible to write a large class of programs or libraries without bothering with .mli files, yet still specify the desired interface; avoiding undesirable decoupling. [NOTE: a decoupled interface is still possible and sometimes it is desirable .. just not always] I am trying this out in Felix, I've implemented 'private' and it seems to work as expected... and was immediately very useful (about 20% of all my library functions turned out to be private, and I also make synthesised names private because it might help catch some compiler bugs) ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners