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