From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Michael Furr <furr@cs.umd.edu>
Cc: Caml List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Recursive module signatures + functors
Date: Tue, 12 Jun 2007 11:47:46 +0200 [thread overview]
Message-ID: <466E6BC2.1080001@inria.fr> (raw)
In-Reply-To: <Pine.SOL.4.33.0706111848240.11389-100000@loompa.cs.umd.edu>
> I've been playing around with using recursive modules to implement mixins
> and don't understand why the type checker fails to accept code below.
> [...]
> I don't quite understand why the type system doesn't know that t and M.t
> are the same.
As Andreas said, this is an instance of the infamous "double vision"
problem. The OCaml module type-checker can deal with this, but the
current implementation is incomplete and works only for generative
type definitions, not for type abbreviations.
Continuing Andreas' example:
module rec M : sig type t val f : t -> t end =
struct
type t = N of int
let f (x : M.t) = x
end
This is accepted because the type-checker can add a type equality
"t = M.t" while type-checking the body of the structure. However,
with a type abbreviation
module rec M : sig type t val f : t -> t end =
struct
type t = int
let f (x : M.t) = x
end
there is already a type equality over t, namely "t = int", and the
current implementation of the type-checker is not able to record and
maintain several type equalities (here, t = int = M.t) over one type
constructor.
Likewise, your example goes through if you put "type t = Constr of ..."
instead of "type t = int".
> Is this a bug in the type checker or is there a reason that it does not
> unify 't' and 'M.t'?
Well, there is a technical reason, but I agree this limitation is a bug.
- Xavier Leroy
prev parent reply other threads:[~2007-06-12 9:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 23:10 Michael Furr
2007-06-12 8:51 ` [Caml-list] " rossberg
2007-06-12 9:47 ` Xavier Leroy [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=466E6BC2.1080001@inria.fr \
--to=xavier.leroy@inria.fr \
--cc=caml-list@yquem.inria.fr \
--cc=furr@cs.umd.edu \
/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