Hell's Parser

[chrisdone]

HSE is a good parser, but not maintained so it's on borrowed time, and doesn't have some modern things like foo.bar record access.

Options:

• Patch HSE. Downside is the bitrot and leaning into a dead library.
• Adopt ghc-lib-parser (fairly laborious rewrite of the desugarer, but not complex). Downside is the sheer size and maintenance burden that inevitably comes from depending on GHC's API (burned enough times..).
• Snatch the parser from Lennart's MicroHS and then shrink it down to what I need. Downside: Bugs? Unexpected programs that parse differently from GHC?
• Write my own parser. Downside: I'm not that motivated to do this once again. And bugs.

HSE not supporting foo.bar kind of forces this thunk, so I'll have to pick something.

[simonmichael]

Speaking of MicroHS, any thoughts of a MicroHS-based version of hell, or is it more of a priority to have totally familiar GHC lib APIs ?

A microhs-based hell would be more portable and lighter to install, and possibly would answer this parser question in a different way.

[chrisdone-artificial]

I think a MicroHS version of Hell might've existed a couple years ago when I was searching for a lightweight no dependencies Haskell interpreter. I think a separate version of Hell, based on MicroHS, would be fun.

But: Today, the kind of scripts we're using Hell for at work are already using concurrency and exceptions and whatnot. The other aspect is that by virtue of stable HSE and GHC's stable runtime, there are no parser bugs and no runtime bugs -- just type-checker bugs (of which there have been a few, but not that many). So the maintenance burden is really, really low for me. A compiler bug triggers at --check time, whereas runtime bugs would happen in our CI pipelines or whatever, and that would be sad and make people second-guess using it.

[simonmichael]

That makes sense. Hell and MicroHell then. :-)

[unhammer]

Heck