220 41137 <16989401-2f0d-4200-997e-0ac60b47bec3@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: "masse.nicolas@gmail.com" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules and preambule, just why? Date: Thu, 29 Nov 2018 14:40:43 -0800 (PST) Lines: 338 Approved: news@gmane.org Message-ID: <16989401-2f0d-4200-997e-0ac60b47bec3@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1098_126005908.1543531243412" X-Trace: blaine.gmane.org 1543531120 31034 195.159.176.226 (29 Nov 2018 22:38:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2018 22:38:40 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCCJBHV4UALBB3GVQHQAKGQEN4QIVRQ@isocpp.org Thu Nov 29 23:38:36 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f199.google.com ([209.85.219.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSUx8-0007wg-VN for gclcip-std-proposals@m.gmane.org; Thu, 29 Nov 2018 23:38:35 +0100 Original-Received: by mail-yb1-f199.google.com with SMTP id n62-v6sf2302030ybg.6 for ; Thu, 29 Nov 2018 14:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=Pgg+rXpY3gDdUlDLs3c9JItvaORY92mco+pwYnebP8Q=; b=rN8k5OF52gQGLC0Bpde1bJu+HmZ14M0TCQYEYCP4drwl0ycD4Z4XpEF7MR6JHtgEyL dOs9YoAj/NY5Rx/MSF8tMA91AGOtkdV253wVL9l0LaZpdRmbQ4GrfH1naz3gPqOeHQWE WsU4mhZdj5Umuqp+QgIj78A8re90v4kXulDTh3SxXR6r1NSA5PTOdIKrRgJcvynwmnva YzeVFdYcMpvdWj8urnb+X7k3g7QJEDqnrAWwIvvorQ0Te2Go7T13x5hKXIdJv0TvH0xX +iUG/Guc9iwQ9MoaSpfBA/rAHV+UCGnB0YSbBwVG6SHGTt/U9GI1yLYrKLUaDoGZOoc9 ehng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=Pgg+rXpY3gDdUlDLs3c9JItvaORY92mco+pwYnebP8Q=; b=MJtD9OzJZ8wqJ7JTBR6NSoE9JGDwixGGocq9kZTu3Qkde9J/jwaGpO5/SzmtYJbYPE hjpVEAsPZ7rQJesP9s+ZGOVXvG5doGCBHJJ1UANSsXje7nZG8y7Rw29CAEU+jWsOhd0W euxxy+E26iIIrDXjvQ4tlzOMePthn3wkBXhPSYGd0Yus6jpP9Yt7FHbuXiu+lqDcoJW7 ibyDqIo+jy4Gn+YSlFnIMJ9ObKZ4NOYKiD8WgUpbzxdzEGT3XVNyO16ccE7Yv2XWssCH jFA4Qndeu2kxHmDUcuCjB7H3KNyZ/vNdcc3D8Dopgn3ZUUVVsnx2SmzIYvgO6q/p7jsP 9ZQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Pgg+rXpY3gDdUlDLs3c9JItvaORY92mco+pwYnebP8Q=; b=DsB5D2psmLWecaA5MvYRIkskgjoX3i6Wr9jCektvhPdH7BKQbHVWj0zlzOr/BK64nG So2keIBnELAMwahTwXhd6pSiwKW38ntn9W7ouD7v+BOTx90jii8JspKWH+LPE/+zNmXW jLD659cD/rz67rnxgghHnhK5WTCTSW6gsUyL++kYlzzSpANqFtO+kIOUkb3KSE/AQDWG 7Uz+2vhUpUr83t6SxM6pOZO+oi1yfxmE5iaD1d2ZC7Qm5JyptxR/m/CH6V0mQARLB8HH Sx++i+dXk2EM/HDWRp5k88TPUmbx8od9UWIuiQdYSC7JvjJxpc9ZegrFy1G25VsmjnqV NMNw== X-Gm-Message-State: AA+aEWbP/kWqEQ6MrFblr0b2cGKUHYOOPC3lnaY344lnJ3g7qypAXQFk 8lvQCkGeaQNkh7ui43Bur9hN+w== X-Google-Smtp-Source: AFSGD/WOfuY9ypPUI2pfRj/gzjGecKXVVbwlub52XRYackb4B2/0TIWACTIT53W6f5pR62hq2k0aNg== X-Received: by 2002:a25:ed5:: with SMTP id 204-v6mr2075663ybo.66.1543531245192; Thu, 29 Nov 2018 14:40:45 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:a082:: with SMTP id x124ls1943148ywg.1.gmail; Thu, 29 Nov 2018 14:40:44 -0800 (PST) X-Received: by 2002:a81:5bc6:: with SMTP id p189-v6mr38478ywb.3.1543531244050; Thu, 29 Nov 2018 14:40:44 -0800 (PST) In-Reply-To: X-Original-Sender: Masse.Nicolas@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41137 Archived-At: ------=_Part_1098_126005908.1543531243412 Content-Type: multipart/alternative; boundary="----=_Part_1099_1279013480.1543531243412" ------=_Part_1099_1279013480.1543531243412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Le mercredi 28 novembre 2018 12:16:53 UTC+1, Klaim - Jo=C3=ABl Lamotte a = =C3=A9crit : > > On Tue, 27 Nov 2018 at 22:10, > wrote:= =20 > > The way modules have been done, they require the sources files to=20 > declare which module they implements and what they exports into a=20 > preambule.=20 > > To be honest, I don't really get why this was necessary.=20 > > My understanding is that the main reason is that it helps tools know=20 > the dependencies without having to parse the rest of the C++ syntax.=20 > Build systems will have to check every source file in a first pass to=20 > quickly decide what have to be built, by making a dependency graph.=20 > This pass is simple if the information is easily locatable and with=20 > always a strict subset of possible C++ syntax.=20 > =20 2 things here: - The dependency graph could be quite hard to compute and will require to= =20 parse every source files. While this is viable on small projects, this=20 could (and probably will) be a problem on large ones. - So far, dependency have always been computed from the build system=20 itself, by specify which files are part of a library, and what other=20 libraries are needed to create each one of them.=20 Basically this is the opposite approach where this information is described= =20 in the build system and is not know by the sources files. And so far, I do= =20 believe this model works well and doesn't require to be changed. =20 Also, the way you phrase it seem to indicate we're modifying the language= =20 to help other tools (not compilers) to deal with it. I hope it's not the=20 case. (also it's similar to other module system from other languages, but=20 > that's not a reason).=20 > Agreed, it's not a reason. =20 > > > Moreover, i found some drawbacks with it:=20 > > - It makes sources files dependent on which modules they will be shippe= d=20 > in.=20 > > I'm not sure I understand this point.=20 > Isn't it the point of modules to associate a module name to sources? =20 I don't think so. I think the point here is how to export the functions, global variables,=20 .... in a more efficient way than using header files (eg: by avoiding to=20 parse and reparse the same code every times an header is included). Note that after reading=20 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf, it seems= =20 they also speaks about "componentization", but i'm usure the current=20 proposal is the best way to achieve it (exporting or not a symbols can for= =20 example already be specified using the visibility attribute when using=20 clang/gcc). > > - Not only the sources does declare the module they belongs to, but the= y=20 > also need to be put together in the build system (may it be Makefiles,=20 > cmake, ...). This goes against the DRY concept since it cause duplication= =20 > of information.=20 > > I don't understand where would be a duplicate information. The module=20 > names exist only in sources, not in build system's project description=20 > files (at least in any decent build system).=20 > > As said above, this is basically the opposite approach. By the way why do= =20 we need to put your files together in the source code inside a module while= =20 we already put them inside the same library or executable at the build=20 system level? > - There is a concept of 'module interface unit' (and even a 'primary=20 > module interface unit'!). As far as I understand it, it is almost the sam= e=20 > that old .h files, thus providing no real benefit over the latter when=20 > writing new code.=20 > > Of course it provides benefit! It's like saying that a header file and=20 > a module is similar, but it's really not. For example, your header=20 > will leak it's names into user's user's code. Modules will not by=20 > default.=20 > The point of these interface unit is to allow you to not change the=20 > interface but change the implementation without the user aving to=20 > recompile their code, even if all the module code is defined in one=20 > file.=20 > The interface/implementation separation is already there when using header= =20 files, so what you describe here seems to me already possible. I'm not sure to get your point here. =20 >=20 > > So, my question is why was this preambule necessary? Can't we avoid it?= =20 > > I'm not an expert, but I believe it is necessary if we want something=20 > that is easy to implement and works well with human readers.=20 > > > Also there seems to be a paper which indicate that preambules are=20 > unnecessary ( > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1299r0.html).=20 > What's the status about this?=20 > > This paper will be published very soon, but you can ask the author for=20 > a copy. Here is the revision 3's intro copy/pasted:=20 > > ---=20 > Module Preamble is Unnecessarily Fragile=20 > > Nathan Sidwell=20 > > The ATOM proposal introduced the module preamble. The merged document=20 > modified that concept=20 > for increased flexibility. The rules determining the extent of the=20 > preamble have been modified, but it=20 > remains fragile. We should consider making the preamble more robust.=20 > TL;DR: This was presented to EWG at the San Diego=E2=80=9918 meeting. It = was=20 > accepted and is merged to=20 > p1103.=20 > > ----=20 > > As you can see, it's a fix of the preamble, not a removal.=20 > =20 Yes, unfortunately. > A. Jo=C3=ABl Lamotte=20 > Thanks for your answer, Masse Nicolas. --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/16989401-2f0d-4200-997e-0ac60b47bec3%40isocpp.or= g. ------=_Part_1099_1279013480.1543531243412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Le mercredi 28 novembre 2018 12:16:53 UTC+1, Kl= aim - Jo=C3=ABl Lamotte a =C3=A9crit=C2=A0:
On Tue, 27 Nov 2018 at 22:10, <masse....@gmail.com> wrote= :
> The way modules have been done, they require the sources files to = declare which module they implements and what they exports into a preambule= ..
> To be honest, I don't really get why this was necessary.

My understanding is that the main reason is that it helps tools know
the dependencies without having to parse the rest of the C++ syntax.
Build systems will have to check every source file in a first pass to
quickly decide what have to be built, by making a dependency graph.
This pass is simple if the information is easily locatable and with
always a strict subset of possible C++ syntax.
= =C2=A0
2 things here:
- The dependency graph could be q= uite hard to compute and will require to parse every source files. While th= is is viable on small projects, this could (and probably will) be a problem= on large ones.
- So far, dependency have always been computed fr= om the build system itself, by specify which files are part of a library, a= nd what other libraries are needed to create each one of them.
Basically this is the opposite approach where this information is descri= bed in the build system and is not know by the sources files. And so far, I= do believe this model works well and doesn't require to be changed.
=C2=A0
Also, the way you phrase it seem to indic= ate we're modifying the language to help other tools (not compilers) to= deal with it. I hope it's not the case.

(also it's similar to other mo= dule system from other languages, but
that's not a reason).
Agreed, it's not a reason.
=C2=A0

> Moreover, i found some drawbacks with it:
> - It makes sources files dependent on which modules they will be s= hipped in.

I'm not sure I understand this point.
Isn't it the point of modules to associate a module name to sources= ?
=C2=A0
I don't think so.
I t= hink the point here is how to export the functions, global variables, ... i= n a more efficient way than using header files (eg: by avoiding to parse an= d reparse the same code every times an header is included).
N= ote that after reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2= 014/n4047.pdf, it seems they also speaks about "componentization"= , but i'm usure the current proposal is the best way to achieve it (exp= orting or not a symbols can for example already be specified using the visi= bility attribute when using clang/gcc).


> - Not only the sources does declare the module they belongs to, bu= t they also need to be put together in the build system (may it be Makefile= s, cmake, ...). This goes against the DRY concept since it cause duplicatio= n of information.

I don't understand where would be a duplicate information. The modu= le
names exist only in sources, not in build system's project descript= ion
files (at least in any decent build system).

As said above, this is basically the opposite approac= h. By the way why do we need to put your files together in the source code = inside a module while we already put them inside the same library or execut= able at the build system level?

> - There is a concept of 'module interf= ace unit' (and even a 'primary module interface unit'!). As far= as I understand it, it is almost the same that old .h files, thus providin= g no real benefit over the latter when writing new code.

Of course it provides benefit! It's like saying that a header file = and
a module is similar, but it's really not. For example, your header
will leak it's names into user's user's code. Modules will = not by
default.
The point of = these interface unit is to allow you to not change the
interface but change the implementation without the user aving to
recompile their code, even if all the module code is defined in one
file.
The interface/implementation separation is already th= ere when using header files, so what you describe here seems to me already = possible.
I'm not sure to get your point here.

=
=C2=A0
>
> So, my question is why was this preambule necessary? Can't we = avoid it?

I'm not an expert, but I believe it is necessary if we want somethi= ng
that is easy to implement and works well with human readers.

> Also there seems to be a paper which =C2=A0indicate that preambule= s are unnecessary (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1299r0.html). What's the status about this?

This paper will be published very soon, but you can ask the author for
a copy. Here is the revision 3's intro copy/pasted:

---
Module Preamble is Unnecessarily Fragile

Nathan Sidwell

The ATOM proposal introduced the module preamble. The merged document
modified that concept
for increased flexibility. The rules determining the extent of the
preamble have been modified, but it
remains fragile. We should consider making the preamble more robust.
TL;DR: This was presented to EWG at the San Diego=E2=80=9918 meeting. I= t was
accepted and is merged to
p1103.

----

As you can see, it's a fix of the preamble, not a removal.
=C2=A0
Yes, unfortunately.


A. Jo=C3=ABl Lamotte

Thanks for your answer,
Mass= e Nicolas.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/16989401-2f0d-4200-997e-0ac60b47bec3= %40isocpp.org.
------=_Part_1099_1279013480.1543531243412-- ------=_Part_1098_126005908.1543531243412-- .