Provide ghc-modi transport?

[alanz]

Would there be any merit in having hie expose a transport that emulates the one ghc-mod uses in its daemon mode?

PROS

• It would allow quick integration into various existing IDEs

CONS

• We would be stuck with it forever
• There is a recognition that it is not an ideal way of doing things. (True?)

[lierdakil]

Okay, first of, IMO ghc-mod legacy interactive interface is horribly broken beyond repair. It doesn't support half of what CLI interface does, and has some problems with argument parsing. It is far from ideal.

But it is widely supported in editors. If you mean HIE to be a drop-in replacement, it is a safe bet. I believe legacy interactive interface won't change much, at least, so it's not like you will have to spend much effort maintaining it.

[alanz]

I guess freezing a bad interface is not a good idea, especially as changes will have to happen in the IDEs using it to bring in the other plugins available.

[lierdakil]

Freezing a bad interface is a fine compatibilty compromise, provided it stays frozen. No fixes, no new features, nothing. That way, legacy software can still work, while newer versions can (and should) use another interface altogether.

In any case, it's up to you if you want to support it. In all honesty, if given an opportunity to switch to a better interface, I won't think twice.

[alanz]

Well, if it freezes, they may as well stay with ghc-mod, so I guess no real
motivation for doing this.

On Sun, Dec 6, 2015 at 9:11 PM, Nikolay Yakimov notifications@github.com
wrote:

Freezing a bad interface is a fine compatibilty compromise, provided it
stays frozen. No fixes, no new features, nothing. That way, legacy software
can still work, while newer versions can (and should) use another interface
altogether.

In any case, it's up to you if you want to support it. In all honesty, if
given an opportunity to switch to a better interface, I won't think twice.

—
Reply to this email directly or view it on GitHub
#125 (comment)
.