Date: Thu, 14 Feb 2019 10:55:23 -0800
On Thu, Feb 14, 2019 at 9:10 AM Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:
> On 14/02/2019 11.51, JF Bastien wrote:
> > On Thu, Feb 14, 2019 at 8:42 AM Matthew Woehlke wrote:
> >> ...then let a tool do it.
> >>
> >> Oh, look! You've invented a portable, intermediate representation!
> >
> > Invention requires novelty. Extracting a header from source isn't novel.
>
> I think you missed the point... which was that, on one hand, you claim
> we don't need a PMIR, while on the other hand explaining how to produce
> exactly that (while seeming to not notice that's what you did).
>
I'll remind you the context: your complaint that you have to maintain
headers. I give you the obvious solution, which EWG discussed quite a few
meetings ago. If you want to call headers "PMIR" and claim novelty, go for
it. Or are we playing some sort of game now? I'm sorry but I'm not
interested. This paper (and subsequent email discussion) was aimed at
helping communication, and the tone of your response it's in that direction.
> >> On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:
> >>>> For projects which don't build zlib++ (as a strawman) as part of their
> >>>> build and instead assume that there is one provided by the system,
> yes.
> >>>
> >>> I don’t think that’s true, based on what my platform offers.
> >>
> >> What is shipped as the module interface? (Is that the same thing that
> >> would be shipped in an IS-modules world?)
> >
> > Our paper covers how clang modules work. We use modules internally (not
> for
> > every project), and we ship headers + binary for some frameworks.
>
> Right. But we're also not copying clang-modules exactly. The objective
> was to determine how things can work in an IS-modules world.
>
> "Divide your sources into interface and implementation like today and
> ship the interface sources" is a possible answer. I'm not sure if we
> have consensus on it, however.
>
Agreed, it's one solution and we can solve it differently. Important to
agree on is that this solution works, and developers using it doesn't
prevent us from standardizing portable module interfaces some other way in
the future. That's one of EWG's key decisions w.r.t. modules.
> > Developers on our platform can use modules if they so desire. Some of our
> > headers are massaged by a variety of tooling.
>
> Right... so you have a tool-generated PMIR. Which happens to look like
> headers.
>
They work with an without modules, and we have a term of art for this:
"header".
> >> Can it be used by every compiler?
> >
> > Depends what you mean by "it".
>
> PMIR's a.k.a. "whatever packages ship that is portable and suitable for
> either being imported directly or generating something which can be
> imported, and need not include the implementation sources".
>
> > Headers and linking work just fine. I also don't think this is
> > relevant.
>
> "Can I use modules without shipping in source form?" seems relevant.
>
That wasn't your question, but yes you can.
> > You should probably talk to Bruno in Kona. I think this would help
> > demystify things even more that what we've tried with our paper.
>
> Alas, I won't be at Kona.
>
wrote:
> On 14/02/2019 11.51, JF Bastien wrote:
> > On Thu, Feb 14, 2019 at 8:42 AM Matthew Woehlke wrote:
> >> ...then let a tool do it.
> >>
> >> Oh, look! You've invented a portable, intermediate representation!
> >
> > Invention requires novelty. Extracting a header from source isn't novel.
>
> I think you missed the point... which was that, on one hand, you claim
> we don't need a PMIR, while on the other hand explaining how to produce
> exactly that (while seeming to not notice that's what you did).
>
I'll remind you the context: your complaint that you have to maintain
headers. I give you the obvious solution, which EWG discussed quite a few
meetings ago. If you want to call headers "PMIR" and claim novelty, go for
it. Or are we playing some sort of game now? I'm sorry but I'm not
interested. This paper (and subsequent email discussion) was aimed at
helping communication, and the tone of your response it's in that direction.
> >> On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:
> >>>> For projects which don't build zlib++ (as a strawman) as part of their
> >>>> build and instead assume that there is one provided by the system,
> yes.
> >>>
> >>> I don’t think that’s true, based on what my platform offers.
> >>
> >> What is shipped as the module interface? (Is that the same thing that
> >> would be shipped in an IS-modules world?)
> >
> > Our paper covers how clang modules work. We use modules internally (not
> for
> > every project), and we ship headers + binary for some frameworks.
>
> Right. But we're also not copying clang-modules exactly. The objective
> was to determine how things can work in an IS-modules world.
>
> "Divide your sources into interface and implementation like today and
> ship the interface sources" is a possible answer. I'm not sure if we
> have consensus on it, however.
>
Agreed, it's one solution and we can solve it differently. Important to
agree on is that this solution works, and developers using it doesn't
prevent us from standardizing portable module interfaces some other way in
the future. That's one of EWG's key decisions w.r.t. modules.
> > Developers on our platform can use modules if they so desire. Some of our
> > headers are massaged by a variety of tooling.
>
> Right... so you have a tool-generated PMIR. Which happens to look like
> headers.
>
They work with an without modules, and we have a term of art for this:
"header".
> >> Can it be used by every compiler?
> >
> > Depends what you mean by "it".
>
> PMIR's a.k.a. "whatever packages ship that is portable and suitable for
> either being imported directly or generating something which can be
> imported, and need not include the implementation sources".
>
> > Headers and linking work just fine. I also don't think this is
> > relevant.
>
> "Can I use modules without shipping in source form?" seems relevant.
>
That wasn't your question, but yes you can.
> > You should probably talk to Bruno in Kona. I think this would help
> > demystify things even more that what we've tried with our paper.
>
> Alas, I won't be at Kona.
>
Received on 2019-02-14 19:55:37