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