From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 38C9B7FE44 for ; Sat, 9 Jul 2016 15:46:30 +0200 (CEST) IronPort-PHdr: 9a23:KpSfBh8HjBuJQP9uRHKM819IXTAuvvDOBiVQ1KB92uscTK2v8tzYMVDF4r011RmSDN2dsKkP1bSempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47AblHf6ke/8SQVUk2mc1EkfqKuQcWM0Yye7KObw9XreQJGhT6wM/tZDS6dikHvjPQQmpZoMa0ryxHE8TNicuVSwn50dxrIx06vru/5xpNo8jxRtvQ97IYAFPyiJ+VrBYBfWX4dNG06+NfsrV2LaAqE5nIRVi9exh9JCAjM4RW8RZD8vTfgsfJV2S+GMMmwRrcxD2eM9aBuHTDhgj0GOjpxy2rXh9Z9luoPrxurvR1yx8jPa4GYLvdkVqzYdNIeA2FGW5ACBGR6HoqgYt5XXKI6NuFCoty4/gNWoA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f180.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.180 as permitted sender) identity=mailfrom; client-ip=209.85.223.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-io0-f180.google.com) identity=helo; client-ip=209.85.223.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BEAADe/oBXhrTfVdFcgnCBJHwGpg+HT4s4gXoihXYCgRsHOBQBAQEBAQEBAREBAQEICwsJIS+CMgQBEgGCEwEEARIRHQEIExYHAQMBCwYFCzcCAiIBEQEFARwGExsHh3MBAw8IDqEYgTE+MYs7gWqCWgWFRgoZJw1Sg0kBAQEBAQUBAQEBAQEBAQEWAgYQhheETYdCgloFjgaLEoFbhDKIRYI4jHSOUBIegQ8PD4JQgXMgMgGJeQEBAQ X-IPAS-Result: A0BEAADe/oBXhrTfVdFcgnCBJHwGpg+HT4s4gXoihXYCgRsHOBQBAQEBAQEBAREBAQEICwsJIS+CMgQBEgGCEwEEARIRHQEIExYHAQMBCwYFCzcCAiIBEQEFARwGExsHh3MBAw8IDqEYgTE+MYs7gWqCWgWFRgoZJw1Sg0kBAQEBAQUBAQEBAQEBAQEWAgYQhheETYdCgloFjgaLEoFbhDKIRYI4jHSOUBIegQ8PD4JQgXMgMgGJeQEBAQ X-IronPort-AV: E=Sophos;i="5.28,336,1464645600"; d="scan'208,217";a="184366378" Received: from mail-io0-f180.google.com ([209.85.223.180]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 Jul 2016 15:46:28 +0200 Received: by mail-io0-f180.google.com with SMTP id t74so65823797ioi.0 for ; Sat, 09 Jul 2016 06:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XogmP8uAdH2WmLd+DjUNRhBJAkhl7S7Y0NaHI5ml/WU=; b=i5kEGSmovYfYB+5QzeMOk1TmeumWtC1MzxlTbUFKcdLqmSnADQ5njG4/05Wxr4TTEx S1tTmHO+Oo7S1XTFT7zvxAD7iE3lZcIi/4GjyG4iM4SJIKBN1+Ukv/w5115kmInjhvxi ED5NM40EXCNS4kZgJLgviCfmvk0qSr1/FfQaCrUoAd5N8C6PAFi92TiOYxyRlmhctax2 C96XHIuejAWG5YTww9TVrCVK4ahKqf9iXM8ISPpy72rMu0ik3Wq9stEqDqOoON3WvRyg KwD7K8B8kjdtrRiqBwxwoqRfoddCAhKLNSdy9v6PTeaqNcLPSJbX4T52UFVuGwty1vfC ELCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XogmP8uAdH2WmLd+DjUNRhBJAkhl7S7Y0NaHI5ml/WU=; b=Asuc2FL5zAqg/kCnZgJeCnKubXGfto4qW5zAoA8NkqRrS48/i9vjVw285MlYXgbqFZ l/VLuA0Op9FzDrTBdxFMQgtXtlhFB2dUOqW2QjGyi8tqYmRQ5KkrSLjLhSGToZ7JyptE oAxN5qDVbkPs81WmCMJn8XxrhKlSrzB2g7ZVI34/nWcIRGwbCasaiNviGX8p6NTih0EW 1kTB9uJcNYqtEi/hNcOZxiV5a9uNCcLQFNvURicX77eN+4vOt6hrWIiLwdw7W2e5P31/ NEsQ7PjlDsNNA4ay83G7ewTKRvYkhcxYYimaYW5QG9KF3MPCPD+p1ZukcfRX809KPe+t GKuQ== X-Gm-Message-State: ALyK8tJR48xaHplbkUYskPsFHxHnNvQ1hLROobZzFU+gbH2J/ZAh8KYtAknHSTIfrXzwegSo7u2syRxCohsPiA== X-Received: by 10.107.139.200 with SMTP id n191mr14145553iod.159.1468071985773; Sat, 09 Jul 2016 06:46:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.130 with HTTP; Sat, 9 Jul 2016 06:45:46 -0700 (PDT) In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CF204AF@IRSMSX102.ger.corp.intel.com> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CF204AF@IRSMSX102.ger.corp.intel.com> From: Gabriel Scherer Date: Sat, 9 Jul 2016 09:45:46 -0400 Message-ID: To: "Soegtrop, Michael" Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=94eb2c057f96378b43053734252e Subject: Re: [Caml-list] ocambuild vs ocamldep circular dependencies --94eb2c057f96378b43053734252e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael, > One can of cause discuss if it is good style to have circular dependencies > between module implementations. One can also discuss if it is the job of a > build tool to enforce such policies, or if a build tool should reduce the > set of valid programs. I think there is a misconception here. The behavior of the compiler in presence of such circular dependencies is undefined. The current implementation happens to allow them, but this does not mean that they are "valid programs". The OCaml language specification is admittedly not very detailed on the relation between OCaml language concepts and filesystem-level files, but you can find a fairly clear explanation of it here: 6.12 Compilation units http://caml.inria.fr/pub/docs/manual-ocaml/compunit.html Compilation units bridge the module system and the separate compilation > system. A compilation unit is composed of two parts: an interface and an > implementation. The interface contains a sequence of specifications, just > as the inside of a sig =E2=80=A6 end signature expression. The implementa= tion > contains a sequence of definitions and expressions, just as the inside of= a > struct =E2=80=A6 end module expression. A compilation unit also has a name > unit-name, derived from the names of the files containing the interface > and the implementation (see chapter 8 for more details). > [...] > A compilation unit can refer to other compilation units by their names, as > if they were regular modules. [...] > In other words, a compilation unit is *a pair* of a .ml file and a .mli file (the latter being optional), and dependencies should be understood at that level. I understand that there is a lot of working code that breaks this model (I personally find it unfortunate), and that large users of OCaml have been taking liberties with the model as they are familiar with the implementation (eg. moving .cmi files around independently from where the compiled implementations are located). This is all fine, but I'm not personally interested in supporting complex unspecified behavior in a build tool (ocamlbuild) that I think has other, more pressing usability issues to adress. I think there are many cases, where two modules are just handling different > aspects of a common complex data structure (in this case a C AST) and the= re > is no natural ordering between them. > The solution I would recommend is to split the shared definitions in a shared module they both depend on. On Sat, Jul 9, 2016 at 8:53 AM, Soegtrop, Michael < michael.soegtrop@intel.com> wrote: > Dear OCaml Users and Developers, > > > > It has been discussed a few times on the list, that ocambuild treats .mli > and .ml files as one regarding dependencies (unlike ocamldep), so that > projects which have dependencies of the type A.ml depends on B.mli and B.= ml > depends on A.mli, cannot be built with ocamlbuild, although they can be > built by other means. > > > > One can of cause discuss if it is good style to have circular dependencies > between module implementations. One can also discuss if it is the job of a > build tool to enforce such policies, or if a build tool should reduce the > set of valid programs. > > > > Let me describe the issue which gives me headaches right now. I am working > on a tool doing certain analysis on C programs. In this tool I have a > module handling types and a module handling constant folding. Both have a > circular dependency in their implementation. Look e.g. at this case: > > > > sizeof(int[3*4])*2 > > > > The type handling module needs to call the constant folding module to get > the value of 3*4. The constant folding module needs to call the type modu= le > for handling the sizeof. There are no easy ways around the circular > dependency here. One way would be to have a mutable value field in my AST > and write the folded values to the AST while doing constant folding, so > that the type module can access the value when it needs it. I have my > doubts that this is nicer than living with the circular dependency. Anyway > I want to be able to decide this and not be forced to a solution by a bui= ld > tool. I think there are many cases, where two modules are just handling > different aspects of a common complex data structure (in this case a C AS= T) > and there is no natural ordering between them. > > > > As a result I would recommend to support in ocamlbuild the same dependency > model as ocamldep has (things are fine as long as .mli files don=E2=80=99= t have > circular dependencies). > > > > The only way I see right now to get my job done is to discard ocamlbuild > and use OcamlMakefile. Since I use menhir =E2=80=93infer, I first have to= modify > OcamlMakefile to handle dependencies in way menhir can live with. > > > > Best regards, > > > > Michael > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > --94eb2c057f96378b43053734252e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,
=C2=A0
One can of cause discuss if it is good style to=20 have circular dependencies between module implementations. One can also=20 discuss if it is the job of a build tool to enforce such policies, or if a build tool should reduce the set of valid programs.

I think there is a misconception= here. The behavior of the compiler in presence of such circular dependenci= es is undefined. The current implementation happens to allow them, but this= does not mean that they are "valid programs".

= The OCaml language specification is admittedly not very detailed on the rel= ation between OCaml language concepts and filesystem-level files, but you c= an find a fairly clear explanation of it here:
=C2=A0 6.12 Co= mpilation units
=C2=A0 http://caml.inria.fr/pub/d= ocs/manual-ocaml/compunit.html

Compilation units bridge the module system and the separate compilation system. A compilation unit is composed of two parts: an interface and an implementation. The interface contains a sequence of specifications, just as the inside of a sig =E2=80=A6 en= d signature expression. The implementation contains a sequence of definitions and expressions, just as the inside of a struct =E2=80=A6 end module expression. A compilation unit also has a name unit-name, deri= ved from the names of the files containing the interface and the implementation (see chapter 8 for more details).
[...]
A compilation unit can ref= er to other compilation units by their names, as if they were regular modules. [...]

In other words, a compilation unit is *a pair* of a .ml file and a= .mli file (the latter being optional), and dependencies should be understo= od at that level.

I understand that there is a lot of wor= king code that breaks this model (I personally find it unfortunate), and th= at large users of OCaml have been taking liberties with the model as they a= re familiar with the implementation (eg. moving .cmi files around independe= ntly from where the compiled implementations are located).

This is a= ll fine, but I'm not personally interested in supporting complex unspec= ified behavior in a build tool (ocamlbuild) that I think has other, more pr= essing usability issues to adress.

I think there are many cases, where two modules are just h= andling=20 different aspects of a common complex data structure (in this case a C=20 AST) and there is no natural ordering between them.

The solution I would rec= ommend is to split the shared definitions in a shared module they both depe= nd on.

On Sat, Jul 9, 2016 at 8:53 AM, Soegtrop, Michael <mi= chael.soegtrop@intel.com> wrote:

Dear OCaml Users and Developers,

=C2=A0

It has been discussed a few times on the list, that = ocambuild treats .mli and .ml files as one regarding dependencies (unlike o= camldep), so that projects which have dependencies of the type A.ml depends= on B.mli and B.ml depends on A.mli, cannot be built with ocamlbuild, although they can be built by other means= .

=C2=A0

One can of cause discuss if it is good style to have= circular dependencies between module implementations. One can also discuss= if it is the job of a build tool to enforce such policies, or if a build t= ool should reduce the set of valid programs.

=C2=A0

Let me describe the issue which gives me headaches r= ight now. I am working on a tool doing certain analysis on C programs. In t= his tool I have a module handling types and a module handling constant fold= ing. Both have a circular dependency in their implementation. Look e.g. at this case:

=C2=A0

sizeof(int[3*4])*2

=C2=A0

The type handling module needs to call the constant = folding module to get the value of 3*4. The constant folding module needs t= o call the type module for handling the sizeof. There are no easy ways arou= nd the circular dependency here. One way would be to have a mutable value field in my AST and write the folded = values to the AST while doing constant folding, so that the type module can= access the value when it needs it. I have my doubts that this is nicer tha= n living with the circular dependency. Anyway I want to be able to decide this and not be forced to a solution by= a build tool. I think there are many cases, where two modules are just han= dling different aspects of a common complex data structure (in this case a = C AST) and there is no natural ordering between them.

=C2=A0

As a result I would recommend to support in ocamlbui= ld the same dependency model as ocamldep has (things are fine as long as .m= li files don=E2=80=99t have circular dependencies).

=C2=A0

The only way I see right now to get my job done is t= o discard ocamlbuild and use OcamlMakefile. Since I use menhir =E2=80=93inf= er, I first have to modify OcamlMakefile to handle dependencies in way menh= ir can live with.

=C2=A0

Best regards,

=C2=A0

Michael

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, ww= w.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


--94eb2c057f96378b43053734252e--