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 1745A5D6 for ; Fri, 21 Sep 2018 05:54:46 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.54,283,1534802400"; d="scan'208";a="347403533" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 21 Sep 2018 07:54:45 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 6A413824F6; Fri, 21 Sep 2018 07:54:45 +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 7F2BB824CF for ; Fri, 21 Sep 2018 07:54:41 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=garrigue@math.nagoya-u.ac.jp; spf=None smtp.mailfrom=garrigue@math.nagoya-u.ac.jp; spf=None smtp.helo=postmaster@ms.math.nagoya-u.ac.jp IronPort-PHdr: =?us-ascii?q?9a23=3Ayq/F1B3hajyKa+mEsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIUI/ad9pjvdHbS+e9qxAeQG9mDtLQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPYQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXXZOUclMWSJBAIyy?= =?us-ascii?q?YYQBAekPPehGqIfwvEcOrQK7BQWwBOPj1j1Fi3nr1qM6yeQhFgTG0RQkEd0UrH?= =?us-ascii?q?vUtcj1O7kJUeuozafH1y/Db+lX2Tfy9YjHbA0qrPaDXb1qa8rR00gvFwzYjlqO?= =?us-ascii?q?soHlOima1vgNs2SB6epvT+2vi2knqg5ruzSv290ghZPViY4PyFDE7Tx0zYAoLt?= =?us-ascii?q?O7UE52ecOoHZVeui2ANoZ6WN4uTm90tCog17EKpIa3cSgJxZg92hLSa/+Kf5KV?= =?us-ascii?q?7h79V+udOyp0iXJndb+5mh2861KvyvfmWcmxyFtKrjRKkt3Ltn0V0hzT8dKLSv?= =?us-ascii?q?5n8Ue92TaDzQbT5ftLIUAzlavUMYctwqMqmpUJrUvPBC32mF3ugK+XcEUr5PSo?= =?us-ascii?q?5vz6brjoqJKQLY55hhvjPqkghsCzG/k0PhUWU2ie4+u81bnj/UPjQLVNi/07iq?= =?us-ascii?q?bZv4rAJcQBp665DBJV3Zg45ha6FTimzNQYkWMBLF1fdxKHiIjoNEvXLPDlF/uw?= =?us-ascii?q?mUijnC1px/DeJrHhGInCLmDfkLf9erZw81JTxxA2zdBb/p5UDrABIOnvWkLqr9?= =?us-ascii?q?zZDho5MxSuzOr9CdV90JkeWWOVDaODPqPSqwzA2uV6CvOIaYldkzHtY6ws/frj?= =?us-ascii?q?i3Q+iXcSeKCo2d0cb3XuTdp8JEDMQ3Pnm8oMCi8ltxAkTeP3hRXWXjdJfXe9Qq?= =?us-ascii?q?8U4zgnCMSgBIjEV4nonfqI12G5BssFNSh9FlmQHCKwJM2/UPAWZXfXe5c5y21W?= =?us-ascii?q?Zf2aU4YkkCqWmkr/wrtjIPDT/3dB55fqyNgz4eTckgA7sCEyBs/b0XnfFzgozF?= =?us-ascii?q?NNfCc/2eVEmWI40k2Ki/EqhvVEFZpV7vxOQw5/KNjVxKp4E4KqA1+TTpKyUF+j?= =?us-ascii?q?B+6eL3QxQ9Y2mYNcZl07Hty+jlbF1iWtErZQivqCD9o26vCE0g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAAAth6RblwuCBoVbGwEBAQEDAQEBB?= =?us-ascii?q?wMBAQGEQWoSKINziHSNPCWYSAEKhGwCg1sGBjQUAQMBAQIBAQEBARMBAQEBAQg?= =?us-ascii?q?WBkwMgjUkAYJeAQEBAQIBIx0BATcBBAsLGAICJgICVwYugwaBegehTm+BLoJ1A?= =?us-ascii?q?QEFgXuCcxmCAwiBC4l8ggCBOQwTgkyEfoMBMYImhkwHgWSGNY4JCZAmF4h0hjC?= =?us-ascii?q?HeYocgmiBWYF2TTg7KgGCQT6BWxqGVYdbYI4JAQE?= X-IPAS-Result: =?us-ascii?q?A0CIAAAth6RblwuCBoVbGwEBAQEDAQEBBwMBAQGEQWoSKIN?= =?us-ascii?q?ziHSNPCWYSAEKhGwCg1sGBjQUAQMBAQIBAQEBARMBAQEBAQgWBkwMgjUkAYJeA?= =?us-ascii?q?QEBAQIBIx0BATcBBAsLGAICJgICVwYugwaBegehTm+BLoJ1AQEFgXuCcxmCAwi?= =?us-ascii?q?BC4l8ggCBOQwTgkyEfoMBMYImhkwHgWSGNY4JCZAmF4h0hjCHeYocgmiBWYF2T?= =?us-ascii?q?Tg7KgGCQT6BWxqGVYdbYI4JAQE?= X-IronPort-AV: E=Sophos;i="5.54,283,1534802400"; d="scan'208";a="279672825" Received: from bsd20.math.nagoya-u.ac.jp (HELO ms.math.nagoya-u.ac.jp) ([133.6.130.11]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2018 07:54:39 +0200 Received: from [192.168.0.12] (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 0CAF38B801F; Fri, 21 Sep 2018 14:54:34 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=math.nagoya-u.ac.jp; s=20160220; t=1537509274; bh=KdRki/QZiE72RTC3f7sUNF/dSYDVrhuhLgys950bElk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZVDVOGDHmV3OboWgMFHEe0+bXszoab8UHw9rZu6BV/4+bAbI1ck9V6gm8cG4hjhol /PFRS1pymdO22F00yHUWxR6zcekcJAWg9p0R1mUxMsv//Fs/NCtQSueAzE4S2JHD6w EoGjryn2cfqphMe2fjMOEQv9eKm3FDdJEpm5h1l4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jacques Garrigue In-Reply-To: Date: Fri, 21 Sep 2018 14:54:32 +0900 Cc: Mailing List OCaml Content-Transfer-Encoding: quoted-printable Message-Id: <1D5C88F1-E691-4124-BBC6-5DB71E00A716@math.nagoya-u.ac.jp> References: To: Arlen Cox X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (ms.math.nagoya-u.ac.jp [0.0.0.0]); Fri, 21 Sep 2018 14:54:34 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99.2 at bsdserver20 X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bsdserver20.math.nagoya-u.ac.jp Subject: Re: [Caml-list] Applicative Functor Madness Reply-To: Jacques Garrigue X-Loop: caml-list@inria.fr X-Sequence: 17080 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: On 2018/09/21 10:25, Arlen Cox wrote: >=20 > Are the actual rules of module equality documented somewhere in the OCaml= manual? It seems you found them. Unfortunately, the OCaml manual does not provide a= formal specification of OCaml, and it sometimes omits some implementation = details. In this case I think it suffices. > It seems like Section 8.12 documents this (at least partially): >=20 > There are several restrictions on module-path: > 1. it should be of the form M0.M1...Mn (i.e. without functor applicatio= ns); > 2. inside the body of a functor, M0 should not be one of the functor pa= rameters; > 3. inside a recursive module definition, M0 should not be one of the re= cursively defined modules. >=20 > Obviously in doing this inside a functor, I violated rule #2. Indeed > What I don't understand is if there are clear syntactic rules, should th= ere not be at least a warning when the rules are violated? The problem is that module aliases were only introduced recently, and reuse= the syntax for module definitions. While =E2=80=9Cmodule M =3D Arg=E2=80=9D in a module is not typed as a modu= le alias, it is still a module definition, and as such there is no reason t= o warn. (But you have a point that at least optionally warning about this c= ould be a good idea.) Another reason is that originally module aliases were introduced as an opti= mization to allow referring to other compilation units without including th= eir whole type in the cmi. This is used in 4.07 to provide a Stdlib module,= which contains just pointers to the modules of the standard library. From = that point of view, it seemed reasonable to keep the same syntax. > Second, how does your solution not still violate rule #1? Because it doesn=E2=80=99t use a module alias, but a destructive substituti= on. A destructive substitution substitutes a module path for a path in the sign= ature, removing this path. Since it removes it, it doesn=E2=80=99t create an alias, and there is no ne= ed for restricting the form of the substituted path. There are other restrictions on where this path is allowed to appear, and s= ome signatures just cannot be inhabited, though. Jacques Garrigue --=20 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=