From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 06CE77EE42 for ; Tue, 4 Jun 2013 10:22:27 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.87,798,1363129200"; d="scan'208";a="20201782" Received: from unknown (HELO [10.1.202.3]) ([194.254.61.161]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 04 Jun 2013 10:22:26 +0200 Message-ID: <51ADA3C2.7020302@inria.fr> Date: Tue, 04 Jun 2013 10:22:26 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: David Allsopp CC: "caml-list@inria.fr" References: <51A81C67.50902@riken.jp> <87bo7rogub.fsf@gmail.com> <51A84283.80309@riken.jp> <51A868F8.9050101@inria.fr> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml 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