Skip to content
This repository was archived by the owner on Oct 7, 2020. It is now read-only.

Use Idris's protocol? #3

Closed
mgsloan opened this issue Oct 22, 2015 · 5 comments
Closed

Use Idris's protocol? #3

mgsloan opened this issue Oct 22, 2015 · 5 comments

Comments

@mgsloan
Copy link
Collaborator

mgsloan commented Oct 22, 2015

As linked from the things-marginally-related list, Idris has quite a nice protocol. It'd be nice to be able to share editor integration effort with the Idris folks, but I'm not sure how much overhead would be involved in making this happen. The primary editor integration seems to be emacs, but it looks like there are official atom, sublime, and vim integrations as well.

I'm not sure how much code reuse we'd get out of this, though. Even with something closer to Haskell, like Idris, I imagine there'd be some things that would need to be done differently in the editor to support Haskell vs supporting Idris. I can imagine sharing code by doing one of the following, using idris-mode as an example:

A) Have idris-mode also directly support Haskell. Of course, things like syntax highlighting would still be the responsibility of haskell-mode.

B) Have idris-mode indirectly supoprt Haskell by providing the necessary hooks and options to make it work well with Haskell.

C) Factor out the shared common code into a separate package, relied on by both idris-mode and haskell-ide-mode (or whatever it's called). Seems like a maintenance burden.

D) Copy-modify code. Yuck!

If going this route, I think I prefer (B), as (C) and (D) seem undesirable, and (A) seems invasive to idris-mode. Considering that idris is written in Haskell, it's imaginable that the Idris folks would be keen on this idea. We'd certainly want their go ahead, as it could lead to additional complexity in their editor plugins.

@alanz
Copy link
Collaborator

alanz commented Oct 22, 2015

Finding the nearest cousin that does close to what we want is probably the best way to go, so we can get something useful as soon as possible.

To this end D) may be a good option, even as a throwaway process to get it clear in our collective heads what needs to happen.

This can potentially leave the door open for either C or B, or even A, depending on how it turns out.

@gracjan
Copy link
Contributor

gracjan commented Oct 22, 2015

I'm very much for this solution. It is something concrete and proven to work well.

@mgsloan
Copy link
Collaborator Author

mgsloan commented Oct 23, 2015

Cool, I'm glad y'all like this approach, I think it's quite promising.

One downside I see to the idris protocol is that many of the response types don't support gracefully adding additional information. In other words, adding fields, which would be ignored by the client. This probably isn't that big of a deal, infact, it may be preferable to instead add new commands which return different response types.

@gracjan
Copy link
Contributor

gracjan commented Nov 6, 2015

Seems we have decided to go by json concatenated streaming. This is what PoC implemented by @alanz does.

Looks like this particular discussion is done! Yey!

(If there is new information you can always reopen or just create a new issue).

@gracjan gracjan closed this as completed Nov 6, 2015
@alanz
Copy link
Collaborator

alanz commented Nov 6, 2015

I disagree.

We have an architecture that supports multiple frontend protocols. Currently there is HTTP/JSON, JSON concatenated streaming/stdio, a basic (debug) console.

More can be added easily.

@alanz alanz added this to the prehistory milestone Feb 2, 2019
jneira pushed a commit to jneira/haskell-ide-engine that referenced this issue Oct 3, 2019
* manual typeclass impls for GhcT

* remove derivingVia language extension
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants