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

[Sven Panne]

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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [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  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


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Sven Panne]

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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users