From: "Yann Régis-Gianas" <yrg@irif.fr>
To: Ocaml Mailing List <caml-list@inria.fr>
Subject: [Caml-list] include two module implementations sharing the same type definitions
Date: Thu, 29 Nov 2018 09:52:53 +0100 [thread overview]
Message-ID: <CAM+Uc3UaYk0zD0sv-p2vj-xbOdA=5tf-OGoZLPXdLh4xy3exYA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
Dear OCaml module hackers,
the recently polished "substitution inside type signature" (described in
Sec 8.11 in the manual) is a real improvement to modularize module
signature developments.
Yet, it seems to me that "include" at the level of module implementations
is preventing us to unleash the full composability power of "include" at
the level of signature. Consider the following example:
``
module type A = sig type t end
module type B = sig type t end
type u = U
module AI : A with type t = u = struct
type t = u
end
module BI : B with type t = u = struct
type t = u
end
module ABI : sig
include A
include B with type t := t
end = struct
include AI
include BI (* This include unfortunately triggers:
Error: Multiple definition of the type name t.
Names must be unique in a given structure or signature.
*)
end
``
I have two questions:
Would it make sense to allow module implementation inclusion to introduce
multiple definitions of a given type name as long as these definitions are
equivalent?
Is there an idiom to work around this (apparent) limitation?
Cheers,
--
Yann Régis-Gianas
[-- Attachment #2: Type: text/html, Size: 1799 bytes --]
next reply other threads:[~2018-11-29 8:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 8:52 Yann Régis-Gianas [this message]
2018-11-29 9:02 ` Danny Gratzer
2018-11-29 9:07 ` Yann Régis-Gianas
2018-11-29 9:08 ` Frédéric Bour
2018-11-29 9:12 ` Yann Régis-Gianas
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='CAM+Uc3UaYk0zD0sv-p2vj-xbOdA=5tf-OGoZLPXdLh4xy3exYA@mail.gmail.com' \
--to=yrg@irif.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