-
Notifications
You must be signed in to change notification settings - Fork 206
Use Idris's protocol? #3
Comments
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. |
I'm very much for this solution. It is something concrete and proven to work well. |
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. |
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). |
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. |
* manual typeclass impls for GhcT * remove derivingVia language extension
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.
The text was updated successfully, but these errors were encountered: