Re: [Caml-list] Why should I use .mli files?

[Edgar Friendly <thelema314@gmail.com>]

On 10/30/2012 12:21 PM, Romain Bardou wrote:
> Le 30/10/2012 17:06, Edgar Friendly a écrit :
>> On 10/30/2012 10:47 AM, Romain Bardou wrote:
>>> Maybe ocaml should provide something like:
>>>
>>> include type t in sig
>>>
>> Is there any case where type declarations in the .mli file should not be
>> included as part of the .ml file?
>
> No, as it does not compile otherwise. However, maybe the user wants 
> the declarations to be put in some specific order.
>
>>> Which would mean "copy-paste the definition of t from the .mli".
>>>
>> Why not have this be the default? i.e. when compiling a .ml file, if the
>> corresponding .mli file exists, its type declarations are in scope for
>> the .ml file, and its value declarations are applied to the
>> corresponding values in the .ml file. The only edge case I can think of
>> is when an identifier is bound multiple times in the .ml file, the type
>> from the .mli file currently only applies to the last binding, whereas
>> with this strategy, the type would most easily be implemented as
>> applying to all bindings of that identifier.
>>
>> E.
>>
>
> I'm not sure I understand what you mean, but here are some examples I 
> worry about.
>
> 1) You have the following .mli:
>         type t = A
>         type u = A
> with the following implementation:
>         let x = A
> Where should type t and type u be copied? In other words, should x be 
> of type t or of type u?
>
They could be copied to the top of the .ml file in the order specified 
in .mli file.
> It may also happen that the user wants the order of t and u to be 
> reversed in the implementation.
>
> 2) You have a declaration like this in the .mli:
>         type t = private something
> Should it be copied as:
>         type t = something
> or as:
>         type t = private something
> I don't think the latter makes much sense most of the time, but it is 
> a valid declaration.
>
Or the user could specify "type t = something" in the .ml file and 
override the .mli file's type.  To do this, we'd need the concept of 
these "copied" types being overrideable in the .ml file, but I think 
doing this would be necessary for backwards compatibility, as all 
existing code would break under the new .mli semantics.

E.