From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id CB0655D6 for ; Thu, 20 Sep 2018 14:30:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.53,398,1531778400"; d="scan'208,217";a="347312822" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 20 Sep 2018 16:30:13 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 8F9FF824E4; Thu, 20 Sep 2018 16:30:13 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 0D920824CF for ; Thu, 20 Sep 2018 16:30:00 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=arlencox@gmail.com; spf=Pass smtp.mailfrom=arlencox@gmail.com; spf=None smtp.helo=postmaster@mail-yb1-f176.google.com IronPort-PHdr: =?us-ascii?q?9a23=3AIOGAaRw8m6bkcdjXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?1e0fIJqq85mqBkHD//Il1AaPAd2Eraocw8Pt8InYEVQa5piAtH1QOLdtbDQizf?= =?us-ascii?q?ssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1?= =?us-ascii?q?JuPoEYLOksi7ze+/94HRbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeu?= =?us-ascii?q?BWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbO?= =?us-ascii?q?SxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDwULs6Wymt771zRRDniC?= =?us-ascii?q?kJOT03/nzJhMNsl69Uug6tqgZlzoLIfI2YNvxzdb7dc9MAQmpBW95cWjBbAoO4?= =?us-ascii?q?cYQPCfcKMPhfr4jyulADqgGxBROoBOzxzD9Hmnj23KIh3uQuFAHJxg0gH9YUvH?= =?us-ascii?q?vIq9X1Mb4fXOaox6fL1TXOd+1a1Sv55YTScR0soeuAUaxtfcfV00UjCgHIg1SW?= =?us-ascii?q?pIf4JT2azP4NvHKe7+d4VeKglWonqwZprziq3Mgsi43JipsVy1/f6Cl12Yg1Kc?= =?us-ascii?q?C6RUN6e9KkH5xQtyaVN4tyXMwuWX1nuCE/yrEeuJ67ejYFyIg/yhLBd/CKd5KE?= =?us-ascii?q?7xHjWeqLPzt0mXZodKiiixuw8EWs0uj8WdO10FZOoCpFiN7MtnUV2hPJ8MiHTu?= =?us-ascii?q?Vy/kG91jaI2AHe8e5EIUUumqraL54t2KI/lp0WsUjbBC/5hF32jLOKdkUj4uWn?= =?us-ascii?q?9/7oYrDippOFM490ixr+Mrg1l8ykAeU4NxAOUHKB9eS90r3j50z5T69Qgv04iK?= =?us-ascii?q?mK+KzdcM8So6r8Bw5Ozq4i7Qy+BnGoyoc2h34CeXtffB+Bx6PuKxmaKer8APG0?= =?us-ascii?q?hESEnzJixvSANbrkVMaeZkPfmavsKO4uo3VXzxA+mIgGtsBkT4oZKfe2YXff8d?= =?us-ascii?q?nRDxs3KQuxmr+1B9B014dYUmWKUPbAbPHi9GSQ7+dqGNGiIZcPsW+kefcg7v/q?= =?us-ascii?q?y3Q+nA1FJPT77d4scHm9W89eDQCZbH7r2IlTFG4Luk8vRrWvhgTdD3hcYHG9W6?= =?us-ascii?q?967TY+Wtqr?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAwCxraNbhrDbVdFbhW0og3OBHYJck?= =?us-ascii?q?EyKeWqOcgsFiCoZBwEEMxUBAwEBAgEBAQEBEwEBAQgLCwgpIwyCNSKDCx0BGx4?= =?us-ascii?q?DEgMGBzcCJAERAQUBUIMGgWkBAxWIO4xogx48iwuBEQUBF4J2BYN3ChkmDViBb?= =?us-ascii?q?wIGEopdF4FBP4wjglcCnG4JggyOGBePIpRmDyGBN4F3MxoIGxVsgjuCM4NPim4?= =?us-ascii?q?jMI10AQE?= X-IPAS-Result: =?us-ascii?q?A0ACAwCxraNbhrDbVdFbhW0og3OBHYJckEyKeWqOcgsFiCo?= =?us-ascii?q?ZBwEEMxUBAwEBAgEBAQEBEwEBAQgLCwgpIwyCNSKDCx0BGx4DEgMGBzcCJAERA?= =?us-ascii?q?QUBUIMGgWkBAxWIO4xogx48iwuBEQUBF4J2BYN3ChkmDViBbwIGEopdF4FBP4w?= =?us-ascii?q?jglcCnG4JggyOGBePIpRmDyGBN4F3MxoIGxVsgjuCM4NPim4jMI10AQE?= X-IronPort-AV: E=Sophos;i="5.53,398,1531778400"; d="scan'208,217";a="279592019" Received: from mail-yb1-f176.google.com ([209.85.219.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Sep 2018 16:29:58 +0200 Received: by mail-yb1-f176.google.com with SMTP id w7-v6so3986519ybm.7 for ; Thu, 20 Sep 2018 07:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yQsEYM8LmBqVmsJRL0K+6gMEjNXxCedFi13faYG088A=; b=fOxAuwymcG+3b9+ZEatCjWhWGXAph7CMVqV4Z9/AHb1JeJNhHS1UVA72LSj5bgaxHu jogSLblBAIs/RSY8ULqLFL7KJibt5Ig5qgKRez5xiqC4OMZiEjED6cIFqTAwAEvaolox sX232Lr/cAlTRRtJcEFbMHiOhZkQ83+WH32JxhKMxofdt8SMBmn53Zy/e5d+CtLyONlT tn2NMAXHHbW3o4YrHzOai3Mlho60KImBdkucvsJ3x1bKXtg1b1IkpRQczHYQPPtZVnSu kXrM0FTksC+l2ZQZR7tFjpN21J0OwoRKLzHkYrTbRBAjl9fUJo7fNIfj9RlaZAfsUS2e s9ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yQsEYM8LmBqVmsJRL0K+6gMEjNXxCedFi13faYG088A=; b=N42HZ1rRO8K33PH+DvMyHH9AwAKgSOtAC6XPJX8bs9G4UxDPVAkC6xWlXiWIF4OLzS ENL+z2rMs8wNPVuPtPmMwtvo8mEGvkljB5UhIxhTd/N/PA6aX89x/0LfOPLcqPeLREc+ fdBA9yOPqikKEHqWIS32KRI4+TKcLc+7v6t2KI+Ue8rYEjJB+LJWQWeFvW8oHEbSamqw 6i2huWYAMfKG2yAdm+s+Qfuxq2OWkIQmrsXPdW1R4espP2tK3jkMqGUZXePWvmJImhyO Yfc1DQQAUmdFoqe1SJxBIqeO7LWPR83DuTFgewf2nR0SGuO+D/bJuMX1JV2qaz0Md2JZ Gj0A== X-Gm-Message-State: APzg51CcOBijGkYM2jh5tZI/TEAiJIcsxs+hJLLa/vIlNkZwKYLQ14id Y5+M/ajpg70bE1k3esAtiZUCEe/vHN1wLkazbl/YF8Y1 X-Google-Smtp-Source: ANB0Vda++oMIheyQ6ZmePuXws0sUVqkirII7NdHDRRb0CeOHXjvwJJ9zBkzsceIPwO2grrqHgWoyl1oOF8qarya//JE= X-Received: by 2002:a25:1fc1:: with SMTP id f184-v6mr17489574ybf.164.1537453797631; Thu, 20 Sep 2018 07:29:57 -0700 (PDT) MIME-Version: 1.0 From: Arlen Cox Date: Thu, 20 Sep 2018 10:29:46 -0400 Message-ID: To: caml-list@inria.fr Content-Type: multipart/alternative; boundary="000000000000776e8f05764e5b86" Subject: [Caml-list] Applicative Functor Madness Reply-To: Arlen Cox X-Loop: caml-list@inria.fr X-Sequence: 17076 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000776e8f05764e5b86 Content-Type: text/plain; charset="UTF-8" Hi everyone, I'm having some trouble getting some code that relies heavily on applicative functors to type check. Does anyone know what I'm doing wrong with this? module type S = sig module T : Set.OrderedType module ST : module type of Set.Make(T) end module Make(T_in : Set.OrderedType) : S (* <- ERROR *) with module T = T_in and module ST = Set.Make(T_in) = struct module T = T_in module ST = Set.Make(T_in) end I get the following error message referencing the above point in the program. Error: In this `with' constraint, the new definition of ST does not match its original definition in the constrained signature: ... Type declarations do not match: type t = Set.Make(T_in).t is not included in type t = Set.Make(T).t File "set.mli", line 68, characters 4-10: Expected declaration File "set.mli", line 68, characters 4-10: Actual declaration It seems to me that since T = T_in, but applicative functors should make the type of Set.Make(T) = Set.Make(T_in). Does this not work this way? Note that if I change the definition of S slightly, the same definition of Make now type checks: module type S = sig module T : Set.OrderedType module ST : Set.S with type elt = T.t end This solution is undesirable because I have a number of modules whose types would require an excessive number of "with module ... = ..." constraints to constrain in this way. Is there a better way of getting this to type check? Thank you, Arlen -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs --000000000000776e8f05764e5b86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= everyone,

I'm having some trouble getting som= e code that relies heavily on applicative functors to type check.=C2=A0 Doe= s anyone know what I'm doing wrong with this?

= module type S =3D sig
=C2=A0 module T : Set.OrderedType
=C2=A0 module= ST : module type of Set.Make(T)
end

module Make(T_in : Set.Order= edType) : S (* <- ERROR *)
=C2=A0 with module T =3D T_in
=C2=A0=C2= =A0 and module ST =3D Set.Make(T_in)
=3D struct
=C2=A0 module T =3D T= _in
=C2=A0 module ST =3D Set.Make(T_in)
end

= I get the following error message referencing the above point in the progra= m.

Error: In this `with' constraint, the n= ew definition of ST
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 does not match = its original definition in the constrained signature:
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Type declara= tions do not match:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 typ= e t =3D Set.Make(T_in).t
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not inc= luded in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type t =3D Set= .Make(T).t
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 File "set.mli"= , line 68, characters 4-10: Expected declaration
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 File "set.mli", line 68, characters 4-10: Actual = declaration

It seems to me that since T =3D T_in, = but applicative functors should make the type of Set.Make(T) =3D Set.Make(T= _in).=C2=A0 Does this not work this way?

Note that= if I change the definition of S slightly, the same definition of Make now = type checks:

module type S =3D sig
=C2=A0 modul= e T : Set.OrderedType
=C2=A0 module ST : Set.S with type elt =3D T.t
= end

This solution is undesirable because I have a = number of modules whose types would require an excessive number of "wi= th module ... =3D ..." constraints to constrain in this way.=C2=A0 Is = there a better way of getting this to type check?

= Thank you,
Arlen


--000000000000776e8f05764e5b86--