From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id C39E67EE6A for ; Sat, 1 Jun 2013 01:13:11 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugAAJ0tqVHAbSoIe2dsb2JhbABZgzmDPLYahSaBAhYOAQELCwoIFAQkgiMBAQUjVhALCQ8CAgUhAgIPBRgxiCAEp3WSEBaBEI17B4JDM2EDjwmINIEqkW+BOQ X-IPAS-Result: AugAAJ0tqVHAbSoIe2dsb2JhbABZgzmDPLYahSaBAhYOAQELCwoIFAQkgiMBAQUjVhALCQ8CAgUhAgIPBRgxiCAEp3WSEBaBEI17B4JDM2EDjwmINIEqkW+BOQ X-IronPort-AV: E=Sophos;i="4.87,781,1363129200"; d="scan'208";a="16382146" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2013 01:13:10 +0200 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178001121.adsl.alicedsl.de [85.178.1.121]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id r4VND84Q011845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Jun 2013 01:13:09 +0200 Received: by first (Postfix, from userid 1000) id B4AD4154066B; Sat, 1 Jun 2013 01:13:08 +0200 (CEST) Date: Sat, 1 Jun 2013 01:13:08 +0200 From: oliver To: Francois Berenger Cc: caml-list@inria.fr Message-ID: <20130531231308.GC6483@siouxsie> References: <51A81C67.50902@riken.jp> <87bo7rogub.fsf@gmail.com> <51A84283.80309@riken.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51A84283.80309@riken.jp> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml On Fri, May 31, 2013 at 03:26:11PM +0900, Francois Berenger wrote: > On 05/31/2013 02:31 PM, Malcolm Matalka wrote: > >I know of no such tool, but in counter to your premise: I used to think > >maintaining a .ml and .mli was foolish, however I no longer do. > [...] [...] > > so it's a valuable check that what I think my module does is also > >what the compiler does. I also tend to write the .mli first, then write > >the .ml. I find it to be a great way to develop. > > I don't. [...] I also not always start with the mli-file, but it is a good way to do it, it#s a good habit. Why? Because the interface is designed first. And the implementation will follow. Especially in teams, this is a really helpful issue: 1.: Let the team agree on a interface (mli-file) 2.: Let the project leader or other person who controls the interface for the modules, create the mli-files. (the interface for modules && responsibility of certain persons for asertain modules => interface between responsibilities) 3.: Put the mli-files into a certain directory, where they have to live. Give read-permissions to all the programmers of the team and write permissions to the mli-files only for the person, who is responsible for them. Then necessarily all programmers of the team know, what the interface is, and can use these files, but not change them. Creating his/her own mli-files will not make sense, sooner or later, the official mli-files must be used. And each programmer can write ml-files in personal style, can write one or more implementations, which need to fir the interface files. But even if these team-worflow would not be used: deigning the interface first (thinking about the program in types) can often be helpful to make the design clear from the beginning. Of course, especially if things are explored rather experimentally, for example if there is a new field of topics, where the interface is NOT clear in advance, starting with the mli-files might be rather a show stopper. if things are rather experimentally, starting with the ml-file might be easier to handle. So, which way to go depends on the field, on the knowledge of the field, on how much planning (of interface) is possible or necessary and if it is done in a team or as a single person. So, both ways have their advantages and disadvantages. camlc -i most often worked for me. In private projects I not necessarily use mli-files always. At job I have to use other languages, but the above mentioned way of read-only mli-files for the programmers of a team would make sense to me. This would make interfaces much clearer in the real world, and IMHO is a good argument for OCaml at work. If some small programs are one at home, and the mli files follow the ml-files, I wonder if they are necessary at all. I sometimes use modules inside a compilation unit, and if they clutter the interface too much, use signatures for these inside-modules, not necessarily for the compilation unit itself. But it depends.... If ocamlc could print both: the default signature of the ml-file, as well as the resulting signature, as delimited by the mli-file, depending on cli-switches, as well as a diff between the ml-file's default signature and the signature provided by the mli-file, this would make handling much easier. Same call of ocamlc, but just change the switch to get the interface of the ml-file, the mli-file's signature or the diff between them, this would be nice. Something like ocamlc -i foobar.ml # prints default sig of foobar.ml ocamlc -ii foobar.ml # prints resulting sig of foobar.ml (either def.-sig or mli-file-sig) ocamlc -id foobar.ml # prints diff between default sig and resulting sig (mli-sig if there is a mli-file) ocamlc -iid foobar.ml # prints diff between resulting sig (mli-sig if there is a mli-file) and default sig Why ocamlc -ii foobar.ml, if 'cat foobar.mli' or 'ocamlc -i foobar.mli' would give the same result? Just because the handling would be unified: same command, same filename, just a different switch. Hope, this does make some sense not only for me ;-) Ciao, Oliver