🚀 go-pugleaf

Le 04/06/2013 09:53, David Allsopp a �crit :
> Romain Bardou wrote:
>> I also used to believe the .mli file should be somehow included in the .ml
>> file. Now I don't.
> 
> +1, FWIW! It's easy to start without the .mli when prototyping and then add it as things mature.
>  
>> But if you design such a tool, here are some things to consider.
>>
>> - Using numbers to order stuff creates some issues of scalability. In
>> particular, inserting a declaration between #3 and #4 may require you to
>> move #4 to #5, #5 to #6 and so on, which (in particular if everything is
>> not in the right order in the implementation) can prove more annoying than
>> reordering stuff in an .mli.
> 
> This is horrible, IMO - any design decision which looks like it'll *require* refactoring support from an editor to be able to work with it strikes me as a bad design decision. If you have hundreds of these in a file, at some point you'll need a "renumber everything" macro.

Agreed, obviously. It seems Fran�ois proposes floats as a solution, but
while it does allow you to insert without renumbering everything, it
seems that with time, you'd end up with a messy file.

> I have wondered if this problem is perhaps looked at the wrong way around - in other words, the complaint takes the form "how can we export to the .mli file automatically" rather than "how can we *import* from the .ml file automatically". The thing I do find irritating maintaining .mli/.ml files is having to type anything out twice - and for the most part that means fully exported type declarations. Say you have a simple module:

I agree with the idea of looking the other way around, but I'm not sure
I agree with your proposal, which seems to *not* be the other way
around: in your example, you write "type t from implementation", in the
mli. I would prefer "type t from interface" from the .ml.

Also, I agree that val and let is not duplication as long as the let is
not annotated. Duplication comes from types and module type
declarations, exceptions, and maybe also classes.

Regarding val and let, if the types don't match, the error is better
located than before in recent versions of OCaml. But it could be even
better if the let could be retyped with inlined type annotations.

Here is an example:

val f: int -> int

let f x = x +. 1.

The error is located on f (it has type float -> float instead of int ->
int). But maybe it would be better if it was located on x or +. as if
the function was actually written like this:

let f (x: int): int = x +. 1.

Why do I bring that up? Well this would go in the sense of avoiding
duplication by avoiding the need of adding the type annotations yourself
to get better error location.

But this brings up other questions, such as: what if a function f is
polymorphic in the implementation and used as such, but is exported as a
monomorphic instance: if you import type annotations from the .mli, you
cannot use the polymorphism of f in the implementation anymore. Unless
the type annotations are only used to obtain better error messages, only
when there is a type mismatch between the mli and the ml.

Cheers,

-- 
Romain Bardou

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs