Date: Sat, 13 Apr 2024 11:32:42 -0700
On Saturday 13 April 2024 08:33:24 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> On Sat, Apr 13, 2024 at 2:13 AM Thiago Macieira wrote:
> > Assume it is and write your proposal. The implementations will either
> > confirm that it is and implement it in the proper way, or they will tell
> > the committee it is impossible.
>
> There are 3 reasons why I preoccupy myself with implementation and why
> I supply a 'possible implementation' for Linux/Microsoft/Apple with my
> papers (much to the dismay of a lot of people here):
>
> (1) It gives the paper a little more impact if the reader can see
> it alive and kicking
> (2) It shows the compiler vendor that what I'm proposing is
> possible (just in case they thought it wasn't possible)
> (3) It shows the compiler vendor that what I'm proposing is
> possible (just in case they don't want to implement it and are lying
> about what's possible)
That's great, but only if your implementation isn't hacky, non-portable and
full of UB. It might show that the data is present so that they can implement
it, but there are other ways of showing the data is present than to use it in
hacky ways.
In my opinion, you're losing time focusing on what's not important. And you're
losing the reader's attention with unnecessary details, which then they will
proceed to critique. That's a disservice.
> So anyway long story short, I'm going to continue to provide
> implementations for Linux/Microsoft/Apple in my papers, even though 9
> times out of 10, the compiler vendor will probably do a better job of
> it than me.
Something about "forest" and "trees" comes to mind.
Proposals wrote:
> On Sat, Apr 13, 2024 at 2:13 AM Thiago Macieira wrote:
> > Assume it is and write your proposal. The implementations will either
> > confirm that it is and implement it in the proper way, or they will tell
> > the committee it is impossible.
>
> There are 3 reasons why I preoccupy myself with implementation and why
> I supply a 'possible implementation' for Linux/Microsoft/Apple with my
> papers (much to the dismay of a lot of people here):
>
> (1) It gives the paper a little more impact if the reader can see
> it alive and kicking
> (2) It shows the compiler vendor that what I'm proposing is
> possible (just in case they thought it wasn't possible)
> (3) It shows the compiler vendor that what I'm proposing is
> possible (just in case they don't want to implement it and are lying
> about what's possible)
That's great, but only if your implementation isn't hacky, non-portable and
full of UB. It might show that the data is present so that they can implement
it, but there are other ways of showing the data is present than to use it in
hacky ways.
In my opinion, you're losing time focusing on what's not important. And you're
losing the reader's attention with unnecessary details, which then they will
proceed to critique. That's a disservice.
> So anyway long story short, I'm going to continue to provide
> implementations for Linux/Microsoft/Apple in my papers, even though 9
> times out of 10, the compiler vendor will probably do a better job of
> it than me.
Something about "forest" and "trees" comes to mind.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Received on 2024-04-13 18:32:48