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 110CC5D4 for ; Wed, 11 Mar 2020 08:28:24 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.70,540,1574118000"; d="scan'208";a="439777765" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 11 Mar 2020 09:28:23 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 1202E7F456; Wed, 11 Mar 2020 09:28:24 +0100 (CET) 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 425037EEA4 for ; Wed, 11 Mar 2020 09:25:41 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=jacques.garrigue@gmail.com; spf=Pass smtp.mailfrom=jacques.garrigue@gmail.com; spf=None smtp.helo=postmaster@mail-wm1-f53.google.com IronPort-PHdr: =?us-ascii?q?9a23=3AgJbxiBNmFnRUrYT/YU4l6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0K/r8rarrMEGX3/hxlliBBdydsK0UzbeO+4nbGkU+or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6a8TWO6msZExD7cA50?= =?us-ascii?q?PfjdG4jIjs3x2frh1YfUZlBqjTGkfL5pZDq/tx/QudQbyd9gI60o1xbS5HRBYf?= =?us-ascii?q?5Xyn5lDV2Wlhf4oMy3+cgwoGxrp/s9+psYAu3BdKMiQOkAVWl0AyUO/MTu8CL7?= =?us-ascii?q?Y06P638bCDhElxNJB03a6Ui/UMqq9CT9seV51W+ROsikFeloCwTn1L9iTVrTsA?= =?us-ascii?q?lCLyQwqTiFhcl5jaYdqxWk9UQmktzkJbqNPf87RZvzONYTRG5PRMFUDnUTDYa1?= =?us-ascii?q?bo9JBO0Eb79V?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+BgBRn2hehjWAVdFlHgELHIVlXIQVg?= =?us-ascii?q?3mLEIIRg26GBnWQVQkBAwEKAQEvBAEBhEMCggocBwEENBMCEAEBBQEBAQIBAgM?= =?us-ascii?q?EARMBAQEICwsIKYVdDII7IoMHAQEBAxIRBBEIARseAwwGBQsNAgImAgIjEQEFA?= =?us-ascii?q?RwTCAEBHoMEgkoBAy6ccYEEPYsofxYFAReDAAWCRYIGChknDWIDgTICBwkBCHw?= =?us-ascii?q?qjCwPgUw/gTiCbT6HXII8IgSXZYkHj0IHgj94BIwmiUMGHY8DEowlpk2EAwIKB?= =?us-ascii?q?wYPI4FGgXpNI1AxgjtQGA2OHRqDWYpWQDOObwEB?= X-IPAS-Result: =?us-ascii?q?A0C+BgBRn2hehjWAVdFlHgELHIVlXIQVg3mLEIIRg26GBnW?= =?us-ascii?q?QVQkBAwEKAQEvBAEBhEMCggocBwEENBMCEAEBBQEBAQIBAgMEARMBAQEICwsIK?= =?us-ascii?q?YVdDII7IoMHAQEBAxIRBBEIARseAwwGBQsNAgImAgIjEQEFARwTCAEBHoMEgko?= =?us-ascii?q?BAy6ccYEEPYsofxYFAReDAAWCRYIGChknDWIDgTICBwkBCHwqjCwPgUw/gTiCb?= =?us-ascii?q?T6HXII8IgSXZYkHj0IHgj94BIwmiUMGHY8DEowlpk2EAwIKBwYPI4FGgXpNI1A?= =?us-ascii?q?xgjtQGA2OHRqDWYpWQDOObwEB?= X-IronPort-AV: E=Sophos;i="5.70,540,1574118000"; d="scan'208";a="341967106" X-MGA-submission: =?us-ascii?q?MDERfSkrE7aDkl/UrfLevyu8rVyeEwCtcLZN76?= =?us-ascii?q?NaZrBkx3T3PEcsgUJu0O5a4A77gUKEj+X78Ie3IBHyGAWZL2YFp922Ff?= =?us-ascii?q?gUkpqbDuOTVjB1DRPAr4ldOMNPYOGiG/xz3WGN27v9d800eHOS8CUL0U?= =?us-ascii?q?/0/Mc3hYoaAyFccLn1UJUoNg=3D=3D?= Received: from mail-wm1-f53.google.com ([209.85.128.53]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 11 Mar 2020 09:25:40 +0100 Received: by mail-wm1-f53.google.com with SMTP id g62so1056722wme.1 for ; Wed, 11 Mar 2020 01:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=gwPaAXurMBkREpNxI6NCeAut3VNfaIy8IAftvI4uIb8=; b=i7294mLrCdnFC4oZzxrHRt+H/p2QztTlsh83+Bo1PyZ5mCfsv80rNm6iUXcCWi6RpW NhPEG9w6IdWXkmtstzYWs651jgO57PPAozZZpbEXxWKtXhkG3tZfOXPfG16PjV5Hc5L+ +hwqiS3I3kzCXbKUiRD8+uU1kpT58f6bZxzILLrFy+/w1+d5+P7drkC7Uy823oS9hypU xKYqORv7zZL06DhI4DTafxzdOLatNEsYzJZ5PAJhwX30LcMhpWzIFMNCPAnSxkNUuYng Q5FIC8Yr3LWuD/zTCb7wdGid9qMzzg8gRB3onuzlWjfgRBAIuQ8ii81s71foARmnPD/h 58zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=gwPaAXurMBkREpNxI6NCeAut3VNfaIy8IAftvI4uIb8=; b=NAHfCZk6l8VBZu4MaKwK97Nj78TdRKz/rWWUcrkaedlOAMTqxE7TJvyKfjlAU+PJvH kkw0vaQIgJdoZNwft2TCifdvM0nzM6qCLR+t+ST0SZnjPOunHl0OCJoqes4yqCrbxvN4 8C6Vld/dcB7S8uOinzk74tHQ020QW1sGehfVhfRKGgBz+HEBBm4Q0Z072u6/FeZ+BJDf ORBl6YkxvzaBadVVSN8HD07B/fpUjHi5N0P7Xf42KxjYULr88RRH8mS/UDry1W9304tJ +I3kvA/Y6Yo8KrGv6dyA6/HRI7rpamS7UxjDH8w8ZIZOEhxm6YbUL7w8Q+yLs3PLgk/i pP0A== X-Gm-Message-State: ANhLgQ28e3Bf5dCvcZyo8piEgkPFPWRK282LHWGhuw3TgKCCj4GALCCt EeG/COITgKa/JRzcaJaZuSI9T5L5Oq0= X-Google-Smtp-Source: ADFU+vswuSgF+yXoQKIQFmwsV3eYcPsjbPhXWgqQO8e/D2kN1DiUQFmsLrtaPij16LxMpOKZzH89cA== X-Received: by 2002:a05:600c:294a:: with SMTP id n10mr2571881wmd.11.1583915139312; Wed, 11 Mar 2020 01:25:39 -0700 (PDT) Received: from [128.93.64.65] (sauternes.paris.inria.fr. [128.93.64.65]) by smtp.gmail.com with ESMTPSA id n1sm24652211wrj.77.2020.03.11.01.25.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2020 01:25:38 -0700 (PDT) From: Jacques Garrigue X-Google-Original-From: Jacques Garrigue To: caml-list@inria.fr References: <5ceb9ffd-943b-b1f2-4851-e4bf528a791d@rochel.info> Message-ID: Date: Wed, 11 Mar 2020 09:25:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <5ceb9ffd-943b-b1f2-4851-e4bf528a791d@rochel.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Validation-by: jacques.garrigue@gmail.com Subject: Re: [Caml-list] Mutually recursive dependent files Reply-To: Jacques Garrigue X-Loop: caml-list@inria.fr X-Sequence: 18049 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: 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