Focus on Haskell IDE Engine #3
Conversation
|
Rust is doing some good work in this area, see https://github.com/rust-lang/rfcs/blob/master/text/1317-ide.md https://github.com/rust-lang/rfcs/blob/master/text/1298-incremental-compilation.md . And I agree with them that good editor support absolutely necessitates rearchitecting the language implementation. However, in the name of performance, their approach is IMO a bit ad-hoc and less correct-by-construction. As a fan of http://blog.ezyang.com/2015/12/the-convergence-of-compilers-build-systems-and-package-managers/ and Nix user, I think getting all our tools to speak the same common language of dynamic dependency graphs is basically the big refactor that is needed. I recently had a good dialogue with @snowleopard in the comments of https://blogs.ncl.ac.uk/andreymokhov/cloud-and-dynamic-builds/ . I don't want to construe the goals of someone else's research, but I'd be thrilled if his work there would lead to exactly the sort of lingua franca I want. In the meantime, shaking our tools up is a good first step. As I recall, the IDE engine is more duct tape around the status quo. It's certainly good to start sharing code between editor modes now, and I don't want to abandon what's been done already, but beyond the short term, I think duct tape adds a lot of complexity that will bite, and these sorts of refactors are already long overdue. |
As long as IDE engine provides a consistent API on what editors can expect (that doesn’t depend on the wrapped tools), the parts can be exchanged later. The One True Solution™ will never exist, it will all be just piecework. Working piecework is often better. |
|
Hi, is there a chance to make some progress here? If not, that's ok, I'll just close this. |
|
Hi, it's been two years since I made this proposal. Can we please move it in one direction or the other? |
|
The proposal says I don't know why would you say that. HIE seems to be worked on very actively. I think it is quite unfair for all these people committing to HIE daily to call this project "abandoned". |
Who's "we"? If you mean "those who work on tooling", then you have to get those people in the room and get buy in, otherwise approving this would be meaningless and e.g. current intero contributors will be likely to continue contributing to intero instead of switching to Haskell IDE engine. If you could go through the list of top contributors from the various tooling project and get them all to join the conversation in this thread, then I think it will be possible to make some meaningful progress towards uniting their efforts. If you mean "the ecosystem committee", then looking at the closed pull requests tab, they don't seem to ever approve or reject proposals. In fact, since the Proposal Process Process document is itself worded as a proposal, could it be that a committee has never been formed, and so nobody feels like they have the authority to accept or reject a proposal? |
|
In fact, there is no "ecosystem committee". The working convention is that it is a place for ecosystem-wide architecture changes to be discussed and individually agreed upon by the various impacted projects. As such, there's not real scope here for discussing community-wide allocation of resources at all -- that is not the purpose of this repo. |
|
Then I think the instructions should be amended to reflect the fact that there is no committee. The Readme points to the proposal for proposals, should I make a PR which rewords that meta-proposal, or should I make a new proposal for proposals, to which the Readme could point to if accepted? |
|
Haskell tools should hop on BSP for interop layer |
|
@Kaishh I have my eye on BSP. And I am hoping that we can end up with some kind of usable REPL story, possibly based on DAP, since there is already https://github.com/phoityne/phoityne-vscode And DAP is now coming to the emacs-lsp client. |
|
Hi all! it's been 3 years since the latest comment and in the meantime the HLS grew and became the de facto standard for IDE tooling (so, 90% of an IDE I'd say). Can we consider this ticket as (happily) resolved? |
Link to rendered proposal: https://github.com/merlinnot/ecosystem-proposals/blob/patch-2/proposals/0000-haskell-ide-engine.rst