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

newer
valid substitutions for holes

older
GHC build broken

Sven Panne

5 Nov 2017 5 Nov '17

3:52 p.m.

2017-11-05 15:37 GMT+01:00 :

...

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.

...

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.

...

especially if those projects are not universally used or required.

This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs? Cheers, S.

Attachments:

attachment.html (text/html — 1.8 KB)

Show replies by date

Ben Gamari

6 Nov 6 Nov

11:54 a.m.

New subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

Next time something like this arises please do open a ticket. Sven Panne writes:

...

2017-11-05 15:37 GMT+01:00 :

...
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

Sven Panne

12:46 p.m.

New subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

2017-11-06 17:54 GMT+01:00 Ben Gamari :

...

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

Yep, will do...

...

Yes, I have opened a differential adding such a flag. See D4164 [1]. Please bikeshed to taste.

Thanks for the quick fix!

...

In general I would really prefer that we *not* consider GHCi's REPL to be a stable programmatic interface.

I fully understand that, and that's definitely the way to go. Nevertheless, parsing tool/compiler output is still one of the most used hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs). Not every project is as open to suggestions and changes as GHC is, so this is often the only way out.

...

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.

That's of course not what was proposed. :-)

...

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.

I think the main problem here was communication. I can't speak for the haskell-mode maintainers, but for my part I didn't notice the problems because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This is definitely part of the whole problem.). I tried the 8.2 series only sparingly and only via the command line, so this is perhaps what others did, too, so the interaction bug went unnoticed for such a long time. Cheers, Sven

Alan & Kim Zimmerman

2:04 p.m.

New subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

To me this is just further evidence that we need a first class API for tool makers. Which is a (slow) work in progress. Alan On 6 November 2017 at 19:46, Sven Panne wrote:

...

2017-11-06 17:54 GMT+01:00 Ben Gamari :

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

Yep, will do...

...
Yes, I have opened a differential adding such a flag. See D4164 [1]. Please bikeshed to taste.

Thanks for the quick fix!

...
In general I would really prefer that we *not* consider GHCi's REPL to be a stable programmatic interface.

I fully understand that, and that's definitely the way to go. Nevertheless, parsing tool/compiler output is still one of the most used hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs). Not every project is as open to suggestions and changes as GHC is, so this is often the only way out.

...
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.

That's of course not what was proposed. :-)

...
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.

I think the main problem here was communication. I can't speak for the haskell-mode maintainers, but for my part I didn't notice the problems because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This is definitely part of the whole problem.). I tried the 8.2 series only sparingly and only via the command line, so this is perhaps what others did, too, so the interaction bug went unnoticed for such a long time.

Cheers, Sven

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

2753

Age (days ago)

2754

Last active (days ago)

List overview

Download

3 comments

3 participants

participants (3)

Alan & Kim Zimmerman
Ben Gamari
Sven Panne