7 ms·
> It tends to have 'first error, breaks rest of compile' problems Sort of. It has a "failure at a stage prevents progress to next stage", so a parse error mea
by tome 2y ago
> It tends to have 'first error, breaks rest of compile' problems
Sort of. It has a "failure at a stage prevents progress to next stage", so a parse error means you won't type check (or indeed, continue parsing). See these proposals for some progress on the matter
* https://github.com/haskellfoundation/tech-proposals/pull/63 https://github.com/haskellfoundation/tech-proposals/pull/63
* https://github.com/ghc-proposals/ghc-proposals/pull/333 https://github.com/ghc-proposals/ghc-proposals/pull/333
- louthy 2y agoI understand why it happens, but it's an absolute killer for refactoring. I didn't mention refactoring in my list because it may just be personal experience: my style of coding is to write fearlessly knowing that I will also refactor fearlessly. So less upfront thinking, more brute force writing (on instinct) & aggressive refactoring. I find I get my solution much faster and it ends up being more elegant. Having a parse error or a type inference error in another module causing all other inference to fail kills the refactoring part of that process where there are syntax/semantic errors everywhere for a period of time whilst I fix them up. It's good to see the issue acknowledged and hopefully resolved in the future. Additionally, it would be good to see some proper refactoring tooling. Renaming, moving types/functions from one module to another, etc.
- tome 2y ago> Additionally, it would be good to see some proper refactoring tooling. Renaming, moving types/functions from one module to another, etc. Doesn't HLS have renaming, at least?