[ghc-steering-committee] Proposal #612: Change semantics of -fhpc to not accumulate data over multiple runs, rec: accept

[Moritz Angermann]

Here's my rationale for a deprecation period.

Someone who uses hpc, might rely on the accumulating behaviour.  They need
a way to be informed about the upcoming change, otherwise they won't know
that they need to pass a new flag going forward (and they can
even start doing that at that point to be defensive). I also hope the
deprecation note would show up in automated tooling, which can then be
proactively adjusted.

To me the compiler is _the_ interface to the end user.  Chances that
someone reads the proposals, GHC changelog are very low. Chances someone
reads the user guide in detail for each GHC release are low as well,
only after the fact, if someone broke will someone start trying to figure
out why something broke. At that point, I think we've lost. They are
frustrated already that something they knew worked just broke.

So to me the deprecation note is basically the signage towards the end
user that uses hpc, that they will need to adjust their ghc invocation if
they rely on the current behaviour, and also a courtesy heads up that the
behaviour
they might rely on changes, _and_ how to adjust and get their old behaviour
(they may need/rely on) back.

To address your two points in detail:
> Is a deprecation period necessary? Or even useful (how do we signal the
upcoming change in default, and how do we expect people would act on it)?
- As the flag currently does not exist, call GHC with hpc without the new
flag will issue a warning. (e.g. current users will be informed).
- The warning message will let the user know what to pass to ghc to retain
the old (current) behaviour, or opt in to the new (future current)
behaviour, depending on their needs.

If we did neither, the user would at some point just notice an existing
workflow magically stopped or in this case even worse, the silent
aggregation of .tix data would stop, and they
might _assume_ the data was the aggregate but it wasn't. A silent change in
default behaviour would be rather painful to notice, debug, and rectify for
users. At least that's my expectation.
(And I know I personally would be furious if a compiler pulled that on me).

Best,
 Moritz

On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> The proposed change seems sensible. At least the argument is convincing. I
> don't use hpc myself, so I don't have an actual design opinion besides
> that. So I vote (weakly) for the proposed new default.
>
> Is a deprecation period necessary? Or even useful (how do we signal the
> upcoming change in default, and how do we expect people would act on it)?
>
> On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Dear Committee members,
>>
>> In Proposal #612
>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder
>> suggests changing the semantics from `-fhpc` to auto-ingest
>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>> and instead overwriting
>> the .tix file with the coverage of the latest run.
>>
>> I agree with his assessment that the current behaviour easily leads to
>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>> this behaviour and defaulting that to _no_, with a grace and
>> deprecation period prior informing the user that the currently accumulating
>> feature will change in a future GHC release.
>>
>> Adding the flag to control this behaviour is fairly uncontroversial I
>> hope, however I'd like you to. Weight in on the default. Should we change
>> the default behaviour, or only add the flag?
>>
>> I'd recommend changing the default to --read-tix-file=no after a
>> deprecation period.
>>
>> Best,
>>  Moritz
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/5f5633e4/attachment.html>