From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 19F787EEA4 for ; Wed, 11 Mar 2020 10:36:09 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=mshinwell@gmail.com; spf=Pass smtp.mailfrom=mshinwell@gmail.com; spf=None smtp.helo=postmaster@mail-io1-f45.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mshinwell@gmail.com) identity=pra; client-ip=209.85.166.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mshinwell@gmail.com"; x-sender="mshinwell@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mshinwell@gmail.com designates 209.85.166.45 as permitted sender) identity=mailfrom; client-ip=209.85.166.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mshinwell@gmail.com"; x-sender="mshinwell@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-io1-f45.google.com) identity=helo; client-ip=209.85.166.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mshinwell@gmail.com"; x-sender="postmaster@mail-io1-f45.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AiX7KYh3CrSR8D5NAsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?segWLPad9pjvdHbS+e9qxAeQG96Eu7QZ06L/iOPJZy8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL3WbmHC57CYTFxPjLkI1?= =?us-ascii?q?Y72tQs+Bx/iwgsK78ITObh4AqzOne7J9MRj++QfYvdALjJAkJa8r0BrGv3ZgdO?= =?us-ascii?q?FfxGcuLlWWyUXS/MC1qbtq6ScYgPIg8dFNVaGyK6EjTb1eEzkiN0g64cTqsV/I?= =?us-ascii?q?Sg7ZtShUaXkfjhcdW1uN1xr9RJqk93Ki7rMsihnfBtX/SPUPYRrn6q5qTBHyjy?= =?us-ascii?q?Jebmw29WjWjop7i6cJ+Uv99Sw6+JbdZcSuDNQ7ZrnUJIpISm9IX8IXXCtEUNvl?= =?us-ascii?q?Mtk/StEZNOMdlLHT4lsDqRzkWFupDeLrjz5P3zr4gfB83OMmHgXLmgcnGoBWvQ?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAAHsGhefy2mVdFlGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBEQEBAQEBAQEBAQEBgXuDFYEHFhSEFVFLgl2LEIIRkzOICwkBAwE?= =?us-ascii?q?MIwwEAQGEQwKCCxwHAQQ0EwIQAQEFAQEBAgECAwQBEwEBCQsLCCeFXwyCOwUBI?= =?us-ascii?q?wEGgngBAQEBAgESEQQZARsdAQMBCwYFCw0qAgIhAQERAQUBHAYTIoMFgkkBAw4?= =?us-ascii?q?gD5xvgQQ9ijN1fw0JBQEXgwAFgUVAgkIKGScNYgOBMgIBBhKBJowsGoFBP4FHg?= =?us-ascii?q?l4+ghtJAoISgmSCPCIEoGyOfkRHgX+HVYVNhRGEOB2bOpd6gjGMIoQcDyOBRoF?= =?us-ascii?q?6TSNQMYI7UBgNjh2Dc4pVRDCNHYFSAQE?= X-IPAS-Result: =?us-ascii?q?A0COAAAHsGhefy2mVdFlGQEBAQEBAQEBAQEBAQEBAQEBEQE?= =?us-ascii?q?BAQEBAQEBAQEBgXuDFYEHFhSEFVFLgl2LEIIRkzOICwkBAwEMIwwEAQGEQwKCC?= =?us-ascii?q?xwHAQQ0EwIQAQEFAQEBAgECAwQBEwEBCQsLCCeFXwyCOwUBIwEGgngBAQEBAgE?= =?us-ascii?q?SEQQZARsdAQMBCwYFCw0qAgIhAQERAQUBHAYTIoMFgkkBAw4gD5xvgQQ9ijN1f?= =?us-ascii?q?w0JBQEXgwAFgUVAgkIKGScNYgOBMgIBBhKBJowsGoFBP4FHgl4+ghtJAoISgmS?= =?us-ascii?q?CPCIEoGyOfkRHgX+HVYVNhRGEOB2bOpd6gjGMIoQcDyOBRoF6TSNQMYI7UBgNj?= =?us-ascii?q?h2Dc4pVRDCNHYFSAQE?= X-IronPort-AV: E=Sophos;i="5.70,540,1574118000"; d="scan'208,217";a="341981113" X-MGA-submission: =?us-ascii?q?MDHEvs/npJmlKMATULHOxvZRQo7j+7KNxxCy5q?= =?us-ascii?q?e4gAfoZbiMNELk/pVm/icbC7fminvaTQILE8er/86wdJWRdgxT781dMl?= =?us-ascii?q?cD9R3wdfeXWWbrI2uDh8dJGm2S6ep/eTLrJCdG+L1NJuoeqItLj0st5Q?= =?us-ascii?q?lPhp7QogEkCHdNA5WaxnJ5FQ=3D=3D?= Received: from mail-io1-f45.google.com ([209.85.166.45]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 11 Mar 2020 10:36:07 +0100 Received: by mail-io1-f45.google.com with SMTP id w9so1173080iob.12 for ; Wed, 11 Mar 2020 02:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YNMDFwSlAj4fZpernilqqc0Hcw6vH3ylXBWhcGxpJ6w=; b=dZRsHgD+TtxYNdHpYgoKaZYmNkyr+jwSFsy1W75NiSpZ4kxeqH2jTKCD+uU24i44ht xgXHH0dz1c7cbFCkY8a7qF/3gRAXKAcDrAiC4P1mb5mLOfI4iwxL7RUCF7vKdsLXQVVA z9rkV5RSuWeF2qUuZoJccMYVpLNdApLgpjVBLsKGDd6/GS67tN8YjdILh1ZQfVtt+9X5 GmfPpT0Rd4hawccAuahkd8MHTscwToHWzJJgL+67cY72r7eJUk1v1QFRWUEr2k+fQ/OR t4Zlf+0R25vruCeGmvIXnL0K7oSKSp53bzjO1aUju0E1gxUqakBYFga70cj4Okp/bV9n hf1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YNMDFwSlAj4fZpernilqqc0Hcw6vH3ylXBWhcGxpJ6w=; b=b5io4rIdl3qumHgugt1y/fMVrFuT//2gQo3hX6JxzfvMBJB7OIBfOYRZKj3JbkA7Av i0ayETx+VPr93gjd4dXOj5rfzYMbSJOIg5Tvk7v+Mk1HQanutxVbmcDY2EYtlf8ukW9H o1VRH+hJdpPC3t/3gE/YqIOxsWYM8GtZFibxFcqbvGz706oiluR6lQzWwMplGN6eAAGg nC2ZjZ4UAiJqS3WDjVvw3Qhi+aa9UoPk6bUcYvShU3YJrX7gB6JBrLe4bgbKdvNXg1WE 7ckbEMCX8XwEm6eu78oKH4gh+p3BQ8Tn4bH45CNfmeNic3vXqq22Ln9XZ3YBRInfbGX1 KbEw== X-Gm-Message-State: ANhLgQ2YJZbxIAJ5aqoCv3OW7S+fmzwBp0XdwY2wd7ASCyi2Ki1PVakm mUZDQpzRa7n/m2WZbyuBRs/Z4AixaScSpuFUqsqhOCId X-Google-Smtp-Source: ADFU+vvZ3o6dyM4LmMHpPjqYv1Ko/9Z7ATT1fMqr0S7uDtR1VyjGgWjQxUqBTNW/YgTGDbQBx1z/eLQR+VEVwe8LaTk= X-Received: by 2002:a05:6602:20cf:: with SMTP id 15mr2111215ioz.24.1583919366322; Wed, 11 Mar 2020 02:36:06 -0700 (PDT) MIME-Version: 1.0 References: <5ceb9ffd-943b-b1f2-4851-e4bf528a791d@rochel.info> In-Reply-To: From: Mark Shinwell Date: Wed, 11 Mar 2020 09:35:55 +0000 Message-ID: To: Jacques Garrigue Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary="0000000000002ebec205a090f778" X-Validation-by: mshinwell@gmail.com Subject: Re: [Caml-list] Mutually recursive dependent files --0000000000002ebec205a090f778 Content-Type: text/plain; charset="UTF-8" We are aiming to address some of these issues with the following proposal, which is being worked on by Jane Street and OCamlPro: https://github.com/ocaml/RFCs/pull/11/files A first version for experimentation should be available fairly soon. Mark On Wed, 11 Mar 2020 at 08:28, Jacques Garrigue wrote: > A relatively short answer. > > There are actually two problems with mutually recursive modules: > one is typing, and the other is initialization. > > If your modules are dependent on each other at the typing level, > in particular if there is a cycle of dependencies between the mli files, > handling this kind of recursion (which is allowed in recursive modules > through a fixed point construction) would require compiling all the > interfaces simultaneously. > This goes against the ocaml policy of separate compilation. > > The initialization problem is a bit simpler to solve, at least if you're > ready to allow some runtime errors for improper recursion. > Basically, one can reuse the scheme of recursive modules, of > starting by first building dummy modules, and then backpatching them > (i.e. writing the concrete definitions inside the structure). > Note that the layout of data in ocaml imposes some severe restrictions > on recursive modules, which could only be solved by changing this > layout. Also, some glue code would have to be generated at link time. > > OCaml has been designed with separate compilation in mind from the > beginning. > This makes handling recursion between compilation units difficult, but > probably not impossible if we consider only the second case. Note > however that > a consequence is the possibility of initialization errors du to bad > recursion. > > Jacques Garrigue > > On 06/03/2020 17:06, Jan Rochel wrote: > > I'm sure that most of you have tripped at one point or another over the > problem > > of OCaml not allowing for module files that mutually depend on each > other. The > > fact that this is possible for modules within the same file raises the > > question: why not for module files? > > > > If I had to guess I'd say that the following reasoning led to that > limitation: > > OCaml's semantics is script-like in that there is not a specific, > explicitly > > defined entry point (such as a main-function in C), but each file is > > interpreted from top to bottom, so the order of the declarations within > a file > > is critically important (due to side effects they may have). This also > pertains > > to the order imposed on the module files before compilation and linking. > (This > > order is either imposed by the user or a dependency generator). Now if > one were > > to allow for recursive module files, then there would be no well-defined > linear > > order imposable on them and therefore the semantics would become > ambiguous. > > > > My first question: > > Is this the actual reasoning behind the limitation or are there other > (perhaps > > more pertinent) reasons? > > > > My contention: > > The above-mentioned ambiguity already exists if a dependency generator > is used. > > If we have modules A -> B <- C, then there are two orders possible: BAC > and > > BCA. A and C may both produce side-effects within B during > "initialisation" and > > unexpected things might happen in B. Given this fact, it should already > be > > considered bad practice to write OCaml programs that are sensitive to > module > > linking order. But if OCaml programs already have to be written with this > > semantic ambiguity in mind, then why not simply allow for mutually > recursive > > module files? > > > > My second question: > > If the answer to my first question is yes, and if my contention is to the > > point, then I'd be curious to to know how difficult it would be to add a > flag > > to the OCaml compiler allowing for mutually recursive dependencies? > > > > Jan > > --0000000000002ebec205a090f778 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are aiming to address some of these issues with the fol= lowing proposal, which is being worked on by Jane Street and OCamlPro:
=

A firs= t version for experimentation should be available fairly soon.

=
Mark

On Wed, 11 Mar 2020 at 08:28, Jacques Garrigue &= lt;jacques.garrigue@gmail.com= > wrote:
= A relatively short answer.

There are actually two problems with mutually recursive modules:
one is typing, and the other is initialization.

If your modules are dependent on each other at the typing level,
in particular if there is a cycle of dependencies between the mli files,
handling this kind of recursion (which is allowed in recursive modules
through a fixed point construction) would require compiling all the
interfaces simultaneously.
This goes against the ocaml policy of separate compilation.

The initialization problem is a bit simpler to solve, at least if you'r= e
ready to allow some runtime errors for improper recursion.
Basically, one can reuse the scheme of recursive modules, of
starting by first building dummy modules, and then backpatching them
(i.e. writing the concrete definitions inside the structure).
Note that the layout of data in ocaml imposes some severe restrictions
on recursive modules, which could only be solved by changing this
layout. Also, some glue code would have to be generated at link time.

OCaml has been designed with separate compilation in mind from the
beginning.
This makes handling recursion between compilation units difficult, but
probably not impossible if we consider only the second case. Note
however that
a consequence is the possibility of initialization errors du to bad
recursion.

Jacques Garrigue

On 06/03/2020 17:06, Jan Rochel wrote:
> I'm sure that most of you have tripped at one point or another ove= r the problem
> of OCaml not allowing for module files that mutually depend on each ot= her. The
> fact that this is possible for modules within the same file raises the=
> question: why not for module files?
>
> If I had to guess I'd say that the following reasoning led to that= limitation:
> OCaml's semantics is script-like in that there is not a specific, = explicitly
> defined entry point (such as a main-function in C), but each file is > interpreted from top to bottom, so the order of the declarations withi= n a file
> is critically important (due to side effects they may have). This also= pertains
> to the order imposed on the module files before compilation and linkin= g. (This
> order is either imposed by the user or a dependency generator). Now if= one were
> to allow for recursive module files, then there would be no well-defin= ed linear
> order imposable on them and therefore the semantics would become ambig= uous.
>
> My first question:
> Is this the actual reasoning behind the limitation or are there other = (perhaps
> more pertinent) reasons?
>
> My contention:
> The above-mentioned ambiguity already exists if a dependency generator= is used.
> If we have modules A -> B <- C, then there are two orders possib= le: BAC and
> BCA. A and C may both produce side-effects within B during "initi= alisation" and
> unexpected things might happen in B. Given this fact, it should alread= y be
> considered bad practice to write OCaml programs that are sensitive to = module
> linking order. But if OCaml programs already have to be written with t= his
> semantic ambiguity in mind, then why not simply allow for mutually rec= ursive
> module files?
>
> My second question:
> If the answer to my first question is yes, and if my contention is to = the
> point, then I'd be curious to to know how difficult it would be to= add a flag
> to the OCaml compiler allowing for mutually recursive dependencies?
>
> Jan

--0000000000002ebec205a090f778--