caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Mark Shinwell <mshinwell@gmail.com>
To: Jacques Garrigue <jacques.garrigue@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Mutually recursive dependent files
Date: Wed, 11 Mar 2020 09:35:55 +0000	[thread overview]
Message-ID: <CA+XF0WAhW=pF0o0xS9RG8gctmi9CN_EsSNkwH2HiZVb--ypvYA@mail.gmail.com> (raw)
In-Reply-To: <f0a0421e-bf24-2a12-58c0-a3a16d8b45ab@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3877 bytes --]

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 <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'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
>
>

[-- Attachment #2: Type: text/html, Size: 4614 bytes --]

      reply	other threads:[~2020-03-11  9:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 16:06 Jan Rochel
2020-03-11  8:25 ` Jacques Garrigue
2020-03-11  9:35   ` Mark Shinwell [this message]

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='CA+XF0WAhW=pF0o0xS9RG8gctmi9CN_EsSNkwH2HiZVb--ypvYA@mail.gmail.com' \
    --to=mshinwell@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=jacques.garrigue@gmail.com \
    /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).