Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: boos@gr6.u-strasbg.fr (Christian Boos)
To: Jocelyn Serot <Jocelyn.Serot@lasmea.univ-bpclermont.fr>
Cc: caml-list@margaux.inria.fr
Subject: Re: Module system and separate compilation
Date: Wed, 20 Mar 96 15:23:42 +0100	[thread overview]
Message-ID: <9603201423.AA21602@gr6.u-strasbg.fr> (raw)
In-Reply-To: <199603190931.KAA11239@nez-perce.inria.fr>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]



[French translation below]

	Hello, 

Here's some comments about your questions :

Jocelyn Serot writes:
 > 
 > (...)
 > 	(* file "bar.ml": *)
 > 
 > 	module type Foo = sig type t val one : t val add : t -> t -> t end
 > 	module type Bar = sig type t val one : t val double : t -> t end
 > 
 > 	module MakeBar(M: Foo) = (struct
 > 		type t = M.t
 > 		let one = M.one
 > 		let double x = M.add x x
 > 	end : Bar)
 > 
 > (...)
 >
 > 	(* file bar.mli *)
 > 	
 > 	module type Bar = sig
 > 		type t
 > 		val one : t
 > 		val double : t -> t
 > 	end

[1] This is the right way. To do the best, you should add :

	'module type Foo = sig ... end '
and	'module MakeBar (M : Foo) : Bar'

in the file "bar.mli".


 > 
 > But this seems contradictory with the fact that, as stated in node2.12 of
 > CSL html manual
 > 
 > "A compilation unit behaves roughly as the module definition
 > 	module unit-name : sig unit-interface end = struct unit-implementation end"
 > 

[2] There's no contradiction. In  the file "foo.mli",  a module Foo is
implicitly declared. This module has type 'sig type t val one ... end'
which is a   sort of "anonymous"  module  type.  In  no way  have  you
declared a module type named Foo, as expected in the "bar.ml" file.


 > Am i missing sth important, or even misusing the module system ?..
 > In particular, the need for textual duplication of the Foo and Bar signatures
 > (which have written and compiled in separate files) in the file defining
 > the functor seems a bit annoying..

[3] I agree with   you that this  duplication  is annoying.  It's only
justification is that a 'module type XXX = sig ... end' statement in a
.mli is a  module type declaration, and that  the same  statement in a
.ml is a  module type definition.  This  allows one to define abstract
module types, for example.  I suggest that the compiler be modified to
automatically  generate module  type  definition   from  module   type
declaration when this declaration is not an abstract one.
  This would eliminate the need for duplication in most cases.


-- Christian Boos.

------------------------------------------------------------------

Bonjour,

Je peux faire quelques commentaires sur vos questions.

[1] C'est effectivement comme cela qu'il faut faire.  Pour bien faire,
il faudrait  encore rajouter la déclaration du  type de module 'module
type Foo = sig ... end '  et celle foncteur  'MakeBar' dans le fichier
bar.mli:

	module MakeBar (M : Foo) : Bar


[2] Non, je ne vois pas la contradiction : le fichier "foo.mli" declare
un module  Foo,  qui se  trouve   avoir un type  (sig  type  t val one
... end), ce type n'étant pas nommé (il n'y a  pas création de 'module
type Foo = sig ... end').


[3] Oui,  alors  là d'accord. Le  fait de  devoir recopier les 'module
type' dans les implémentations est pénible et source d'erreur. Cela se
justifie parceque dans le .mli il s'agit de déclaration et dans le .ml
d'une définition. Cette séparation  permet par exemple de déclarer des
types de modules abstraits  ('module type Foo'). Mais  la plus part du
temps, il serait plus pratique de générer la définition à partir de la
déclaration du .mli.







      parent reply	other threads:[~1996-03-20 16:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-03-19  9:29 Q: " Jocelyn Serot
1996-03-20 13:49 ` Wolfgang Lux
1996-03-20 14:23 ` Christian Boos [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9603201423.AA21602@gr6.u-strasbg.fr \
    --to=boos@gr6.u-strasbg.fr \
    --cc=Jocelyn.Serot@lasmea.univ-bpclermont.fr \
    --cc=caml-list@margaux.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox