🚀 go-pugleaf

Romain Bardou wrote:
> 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.

Yes - I'd said in a private exchange that using floats is no different from the way Basic programmers used to leave gaps between line numbers! Eventually you need to renumber...

> > 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.

My perspective was that it looks at what we write in the .ml file being *exported* to the .mli file and I was proposing that what we write in the .mli file be *imported* from the .ml file (which I would say is indeed the other way around). But as I said in response to Alain, perhaps that's not actually the good idea I thought it was, given that .mli files are used in contexts where the .ml file isn't available. I agree that putting the copy statement in the .ml file is better. 

> 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.

I guess that depends on what you regard as the error, though - the definition of [f] with floats is not incorrect, it just doesn't comply with the signature you've imposed. Personally, I'm happy with the idea that the compiler reports that the signature of [f] differs between the implementation and interface and leaves me to figure out why that's a mistake, but... 

> 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.

That's kind of why I was thinking that you only have an "extension" for types which are *actually* duplicated between the two. However, perhaps it's something that is relatively easy with the kind of extension Alain proposes so that you could write in the .ml file:

let [%unify_typedef] f = x +. 1.

so that you're saying that the type of [f] must be unifiable (rather than copied) from the .mli... which would catch the case of f : float -> float and state that either [+.] or [x] is the problem but also allow you to have a polymorphic function in the implementation with a monomorphic exported type.


David

-- 
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