From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: chrisg@cs.uoregon.edu
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] type issues with modules
Date: Tue, 11 Nov 2003 17:21:47 +0900 [thread overview]
Message-ID: <20031111172147M.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <3FB0749C.80103@cs.uoregon.edu>
From: Chris GauthierDickey <chrisg@cs.uoregon.edu>
> I have a weird issue, but I'm not sure if it's related to the type
> system or what's really going on. I've boiled the problem down to the
> simple case below. I have 4 files, two that are interfaces for the modules.
>
> file: mod1.mli
> type t1 = T1
> val v: t1
>
> file mod1.ml
> type t1 = T1
> let v = Mod2.f2 ()
>
> file mod2.mli
> val f2: unit -> Mod1.t1
>
> file mod2.ml
> let f2 () = Mod1.T1
>
>
> I compile the files as such:
>
> ocamlc -g mod1.mli
> ocamlc -g mod2.mli
> ocamlc -g mod1.ml
>
> at which point I get the error:
> The implementation mod1.ml does not match the interface mod1.cmi:
> Values do not match: val v : Mod1.t1 is not included in val v: t1
Explanation:
As specified in the reference manual, the combination of .ml and .mli
is expected to mean:
module type Sig_mod1 = sig <mod1.mli> end
module Struct_mod1 = struct <mod1.ml> end
module Mod1 : Sig_mod1 = Struct_mod1
This means that during the typing of the contents of mod1.ml, the
compiler does not know yet that it is defining Mod1 (no recursion).
As a result, the t1 in mod1.ml and the Mod1.t1 in mod2.mli are not
known to represent the same type. Hence the error.
Moreover, the possibility of creating mutual dependencies between
modules by compiling a module against a .mli of another module
depending on the first one is not intentional, and should probably not
be relied upon.
> P.S. I know I can move t1 into another module, but for software
> engineering reasons, I don't want to do that.
I'm wondering what you mean by software engineering reasons.
That you want to keep types and values in the same module?
Unfortunately, this does not work well with the absence of recursion
between modules. Putting all types in a third module is indeed the
simplest solution.
Jacques Garrigue
-------------------
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
next prev parent reply other threads:[~2003-11-11 8:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-11 5:33 Chris GauthierDickey
2003-11-11 8:21 ` Jacques Garrigue [this message]
2003-11-11 17:25 ` Damien
2003-11-12 1:12 ` Jacques Garrigue
2003-11-12 12:51 ` Remi Vanicat
2003-11-13 21:31 ` Issac Trotts
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=20031111172147M.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=chrisg@cs.uoregon.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;
as well as URLs for NNTP newsgroup(s).