[Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

[Ben Gamari]

Next time something like this arises please do open a ticket.


Sven Panne <svenpanne at gmail.com> writes:

> 2017-11-05 15:37 GMT+01:00 <jpaugh at gmx.com>:
>
>> A better approach might be to develop a "machine-readable" output format
>> which then is kept stable, and can be enabled with a flag. Git has a
>> similar solution.
>>
>
> Without doubt, this is definitely the better approach, but this is hardly
> what can be achieved for 8.2.2. Adding some flag to get the old behavior
> back when wanted *is* achievable.
>
Yes, I have opened a differential adding such a flag. See D4164 [1].
Please bikeshed to taste.

In general I would really prefer that we *not* consider GHCi's REPL to be
a stable programmatic interface. If haskell-mode needs access to some
bit of information from GHC, then please let's discuss how to provide it
in a more robust manner. This shouldn't be hard; we just need to have
feedback on what the interfaces required should look like.

[1] https://phabricator.haskell.org/D4164

>
>> It would be a shame to avoid changes which make the user experience better
>> simply because other projects cannot sync their development cycle,
>>
>
> Don't get me wrong: I'm all for improving user experience, but making ad
> hoc changes without enough thought or even a chance to get the old behavior
> back is probably not the right way to proceed. All SW lives in some kind of
> ecosystem, so it should behave well in that. And for Emacs users, the user
> experience has been made much worse.
>
The trouble is that GHC has an extremely large surface area, any bit of
which might have mechanical consumers. Those who reviewed the patch
indeed considered making this change behind a flag (as Francesco's
original patch did) but we concluded that this would be pointless as it
didn't seem likely that anyone relied on this behavior. It seems that in
this case we were wrong

That being said, we cannot always preemptively add complexity to the
project out of fear that a given change might break a hypothetical
mechanical consumer. GHCi is first-and-foremost a REPL for users. 
When evaluating a change, if we feel it is likely that we will break a
mechanical user then we will likely guard the change with a flag.
However, if not, we won't.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171106/0ebf0550/attachment.sig>