caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Tom Hirschowitz <tom.hirschowitz@inria.fr>
To: caml-list@inria.fr
Subject: [Caml-list] Pb with type constraints in module
Date: Wed, 19 Feb 2003 11:49:38 +0000	[thread overview]
Message-ID: <15955.28498.491350.48269@paille.inria.fr> (raw)
In-Reply-To: <15955.25572.723415.666471@paille.inria.fr>


Better explanation: a typedecl is a type identifier, plus a declaration, right?
Now, how do you parse "S with type A.t = A | B"?

Tom Hirschowitz writes:
 > 
 > I don't know of any formalization of these "with" contraints, but the
 > current meaning is that typexpr must be a type in the outer
 > environment.  If the declaration "S with type t = typexpr" is written
 > in the environment E, typexpr must be a valid type in E (and thus
 > cannot refer to t).  The constraint is then propagated through the
 > module type S.  In fact, "t" here is not exactly considered a type
 > identifier, but rather an access path into the constrained module
 > type.  So, any reference to t in typexpr is considered a reference to
 > an upper definition of t, contrarily to what is done in type
 > declarations.
 > 
 > Therefore, you example is not correct in this setting, since the
 > references to t are wrong. It should not be too difficult to allow
 > datatype declarations though, while preserving this semantics, by
 > having a function for scoping datatypes non-recursively. I am not sure
 > about the gain of expressive power though, since for instance your
 > example would remain incorrect.
 > 
 > Last remark: "with" constraints do propagate datatype
 > declarations, as soon as you use modules instead of types.
 > 
 > For example:
 > 
 > # module A = struct type t = A | B of t end;;
 > # module type T = sig module A : sig type t end end;;
 > 
 > # module type T' = T with module A = A;;
 > module type T' = sig module A : sig type t = A.t = A | B of t end end
 > 
 > 
 > Cheers.
 > 
 > Christophe Raffalli writes:
 >  > 
 >  > Is there a good reason to have this in the grammar
 >  > mod-constraint ::=
 >  >    type [type-parameters]  typeconstr =  typexpr
 >  > | module module-path =  extended-module-path
 >  > 
 >  > instead of
 >  > mod-constraint ::=
 >  >    type typedef
 >  > | module module-path =  extended-module-path
 >  > 
 >  > Here is an example where this is useful:
 >  > 
 >  > Lets say you have  a nice module type and functor:
 >  > 
 >  > --
 >  > module type Ord =
 >  >    sig
 >  > 	type t
 >  > 	val compare : t -> t -> int
 >  >    end
 >  > 
 >  > module F(G:Ord) =
 >  >    struct
 >  > 	type t = Empty | Node of G.t * t * t
 >  > 	let compare = ... the code you want ...
 >  >    end
 >  > --
 >  > 
 >  > in a .mli you may want to write
 >  > 
 >  > --
 >  > module F : functor (G:Ord) -> Ord
 >  >    with type t = Empty | Node of G.t * t * t
 >  > --
 >  > 
 >  > And this is not legal because "with type" take a typeexpr and not a 
 >  > typedef. This is not very natural, bacause you have to move the 
 >  > definition of t outside F like in
 >  > --
 >  > type 'a tree = Empty | Node of 'a * 'a tree * 'a tree
 >  > module F(G:Ord) =
 >  >    struct
 >  > 	type t = G.t tree
 >  > 	let compare = ... the code you want ...
 >  >    end
 >  > --
 >  > 
 >  > in a .mli you can now write
 >  > --
 >  > type 'a tree = Empty | Node of 'a * 'a tree * 'a tree
 >  > module F : functor (G:Ord) -> Ord with type t = G.t tree
 >  > --
 >  > 
 >  > The same happends if you use recursive type
 >  > --
 >  > module F : functor (G:Ord) -> Ord with type t = (G.t * t) list
 >  > --
 >  > is not legal either.
 >  > 
 >  > -- 
 >  > Christophe Raffalli
 >  > Université de Savoie
 >  > Batiment Le Chablais, bureau 21
 >  > 73376 Le Bourget-du-Lac Cedex
 >  > 
 >  > tél: (33) 4 79 75 81 03
 >  > fax: (33) 4 79 75 87 42
 >  > mail: Christophe.Raffalli@univ-savoie.fr
 >  > www: http://www.lama.univ-savoie.fr/~RAFFALLI
 >  > ---------------------------------------------
 >  > IMPORTANT: this mail is signed using PGP/MIME
 >  > At least Enigmail/Mozilla, mutt or evolution
 >  > can check this signature
 >  > ---------------------------------------------
 > -------------------
 > To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
 > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
 > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
 > 
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


      reply	other threads:[~2003-02-19 11:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-11 20:02 [Caml-list] fermer un listbox, (ou detruire ) deerf hal
2003-02-12  3:05 ` [Caml-list] Pb with type constraints in module Christophe Raffalli
2003-02-19 11:00   ` Tom Hirschowitz
2003-02-19 11:49     ` Tom Hirschowitz [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=15955.28498.491350.48269@paille.inria.fr \
    --to=tom.hirschowitz@inria.fr \
    --cc=caml-list@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;
as well as URLs for NNTP newsgroup(s).