caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jeremy Yallop <yallop@gmail.com>
To: Oleg <oleg@okmij.org>, Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Are record types generative?
Date: Tue, 23 Jan 2018 16:05:46 +0000	[thread overview]
Message-ID: <CAAxsn=GU_NBNAs=DJi0EZqibtZOgr2cOugXqkYdDU+Su7-qUzw@mail.gmail.com> (raw)
In-Reply-To: <20180123145453.GA1916@Magus.localnet>

On 23 January 2018 at 14:54, Oleg <oleg@okmij.org> wrote:
> Although both M2 and S are two instances of m2, and hence both
> S.v and M2.v  should have the record type t = {l:int}, they are not
> regarded equal.

Yes: record definitions are indeed generative in OCaml, unlike in Standard ML.

> The problem is easy to fix:
>
> module F3(S:m2 with type t = M2.t) = struct
>   let res = S.v = M2.v
> end
> ;;
>
>   module F3 :
>   functor (S : sig type t = M2.t = { l : int; } val v : t end) ->
>     sig val res : bool end
>
> let _ = let module M = F3(M2) in M.res;;
>
> but even in this simple case the fix is ugly (and becomes uglier in
> the real code). Maybe there is a way to avoid adding too many sharing
> constraints?

One approach is to ensure that record and variant declarations do not
appear in signatures, so that type members in signatures are just
equations that refer to top-level types.  Then your example could be
written like this:

    type s = {l:int}

    module type m2 = sig
      type t = s
      val v : t
    end

    module M2 : m2 = struct
      type t = s
      let v = {l=1}
    end

    module F2(S:m2) = struct
      let res = S.v = M2.v
    end

Things become a little trickier if the type definition refers to other
elements in the signature

   module type m3 = sig
      type a
      type t = {l:a}
       ...

Losing equalities between different instances of 't' may in fact be
the desired behaviour here, since 'a' can be instantiated differently
in each implementation of the module.  But if it's important to keep
equalities then parameterising the record can help:

   type 'b s = {l:'b}

   module type m3 = sig
      type a
      type t = a s
       ...

> BTW, the new manual has a section about common polymorphism
> pitfalls. Modules also have a fair share of dark corners (along with
> the objects). Perhaps there could be a section in the manual about
> not so obvious aspects of modules (in the first approximation,
> just collecting questions and answers like the present one).

I think that'd be very useful.

  reply	other threads:[~2018-01-23 16:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 14:54 Oleg
2018-01-23 16:05 ` Jeremy Yallop [this message]
2018-01-23 17:39   ` Chet Murthy
2018-01-23 20:35     ` Jeremy Yallop
2018-01-23 21:36       ` Chet Murthy
2018-01-23 22:06         ` Jeremy Yallop
2018-01-23 23:14           ` Hendrik Boom
2018-01-24  1:06             ` Chet Murthy
2018-01-24  1:35             ` Francois BERENGER
2018-02-07  2:00               ` [Caml-list] [ANN] first release of bst: a bisector tree implementation Francois BERENGER
2018-02-07 12:40                 ` Ivan Gotovchits
2018-02-08  0:46                   ` Francois BERENGER
2018-01-24  1:56             ` [Caml-list] Are record types generative? Yawar Amin
2018-01-25 10:49               ` Matej Košík
2018-01-25 13:39                 ` Simon Cruanes
2018-01-25 16:24                 ` Yawar Amin
2018-01-24  1:05           ` Chet Murthy
2018-01-24  8:43             ` Jacques Garrigue
2018-02-02 23:07               ` Toby Kelsey
2018-02-02 23:23                 ` Evgeny Roubinchtein
2018-02-04  1:27                 ` Jacques Garrigue

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='CAAxsn=GU_NBNAs=DJi0EZqibtZOgr2cOugXqkYdDU+Su7-qUzw@mail.gmail.com' \
    --to=yallop@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=oleg@okmij.org \
    /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).