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

[Eric Seidel]

The change itself makes sense to me, non-accumulating semantics seem like
a much better default.

I also think this is a case where users should be expected to read the
Release Notes. Just highlight the change of default behavior at the top
and move on.

On Fri, Jan 26, 2024, at 15:22, Adam Gundry wrote:
> If we want to "break it completely", we could introduce a third option 
> --read-tix-file=error which will throw an error if an existing .tix file 
> is present (much as will currently happen sometimes if a stale .tix file 
> is there, but with a better error message).
>
> The deprecation process could then start by introducing a warning if 
> --read-tix-file is not specified (while --read-tix-file=yes remains the 
> default), then make --read-tix-file=error the default for a release or 
> two, before finally adopting --read-tix-file=no as the default we 
> actually want.
>
> Is all this worth it? I'm not sure. It seems quite a lot of bureaucracy 
> and extra work for David and the rest of the GHC team. At some point, 
> perhaps we should expect users to read the release notes if they are 
> upgrading the compiler and experiencing changes?
>
> Cheers,
>
> Adam
>
>
> On 26/01/2024 16:46, Simon Marlow wrote:
>> Moritz - I agree with everything you say about how users will typically 
>> experience the change, but I don't think a deprecation warning resolves 
>> the concern. As you say, people might be using HPC via automated tooling 
>> and will likely not even see the warning, and even if they do see it 
>> will likely ignore it (I don't know about you, but I don't usually want 
>> to be distracted by some different yak that needs shaving while I'm coding).
>> 
>> IMO we either have to break it completely - i.e. make the existing usage 
>> just fail, after a warning cycle - or don't change it at all. We can't 
>> silently change the behaviour even with a deprecation cycle.
>> 
>> Cheers
>> Simon
>> 
>> On Thu, 25 Jan 2024 at 10:49, Moritz Angermann 
>> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> 
>>     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 <mailto: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 <mailto: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
>>             _______________________________________________
>
>
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee