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