[Dream] Toward another compiler?

That’s awesome. I’ll look forward to the recording!

1 Like

I really, really hope this is not the case. DH has sucked all of the air out of the room and delivered … nothing. In fact, I now realize GHC has been preparing for DH since about 2016 and delivering nothing.

So if there’s to be another Haskell, I want it to take the language as at 2016 (Pattern Synonyms) and continue all the half-finished other stuff – like FunDeps with Overlapping, a records system, Datatype contexts done per GHC before ~1999 (to get an industrial-strength approach in the same space as GADTs), …

I see no merit in a competing compiler merely mimicking the language GHC supports, whatever its underlying technology.


…that depends on what is meant by “denotative” here:

  • more “mathematical”: then according to this article at least, it seems laziness ought to be a second-class feature - Haskell should be eager by default.

  • no effects: I frequently see articles which refer to non-termination as being an (undesirable) effect - that being the case, a denotative Haskell would also be a total Haskell.
    (which then also has consequences for dealing with I/O…)

Having referred to the monadic IO type as being “lawless”, Ben Lynn’s Zurihac 2023 presentation is also of interest to me…

I’ve given some thought to the questions you raise. I’ve been slowly developing another parser for Haskell with GHC extensions, and it’s at a point where I have to consider whether to extend it toward a proper compiler or alternatively to direct my efforts toward tools for tinkering with the source code - pretty-printer, linter, refactoring etc.

For anybody who seriously wants to develop an alternative Haskell compiler, the first step should probably be to decide which market niche they’d target that’s not well served by GHC. Here are some ideas:

  • smaller and simpler compiler to tinker with
  • new language extensions not likely to to be supported by GHC for some reason
  • better JavaScript back-end, with full Haskell 2010 compatibility but no GHC RTS support
  • JVM or CLR interoperability – though the fate of previous efforts does not inspire confidence
  • completely new runtime supporting massively parallel or distributed execution
  • bottom-up design for integration with novel development tools

Unless you have no higher goal than to have fun – and I’m in full agreement compiler developent can be fun – you should really come up with a goal that’s not attainable by tweaking GHC. Having two viable Haskell compilers would hopefully have a pleasant effect of finally providing enough reason to update the Haskell Report, but first you need to have another viable compiler with actual users.


I think this is probably the most immediately compelling niche (at least for my cross-section of interests and the state of the art), though a more hackable Haskell compiler (i.e., the first bullet) could pay dividends in lots of directions.


You would have to say first, what Haskell means for you. Haskell 98? 2011? 2021? 2011 plus your favourite extensions? Whose favourite extensions? Choose wisely so you will be able to use some libraries in order to bootstrap your compiler.

I think your endeavour stands and falls with a good reason or motivation to develop a compiler.

Do you want to give the Haskell ecosystem an alternative to GHC? Good luck, you will have to allocate developer decades of work for that. I don’t believe the need for that is high enough to make such an investment. GHC has no problems that are that pressing to develop an alternative.

Do you want an academic project? Fair enough, should be possible, there are certainly many ideas that could be explored in a small, newer compiler. If you have a great idea, it might be worth the cost. But many great ideas have already taken that route and established a Haskell dialect exploring it. Better Javascript support? Purescript. Logic programming? Curry. Dependent types? Agda, Idris. The list goes on. You would have to have a great idea like “what if Haskell could do X”, and then justify why not to implement it as a GHC language plugin instead in order to motivate people to do this.


…and now someone seems to have done so: thank you, @turion.

A proverbial “wildcard”: program verification similar to what the PureCake Haskell-subset language implementation uses (by being based on CakeML)…

I haven’t done so at all, I’m wondering where the misunderstanding lies.

@jhenahan @blamario
Regarding a distributed Haskell runtime, I have a wacky idea, but I’m still in the stages of making a toy example to prove whether or not it is brilliance or idiocy, and I hesitate to make bold claims without evidence to back them up. Suffice to say that distributed Haskell is of great interest to me, and I have a teeny lambda calculus with a module system that I’m trying to apply said wacky idea to.

Ben Lynn’s Compiler Quest series has held a permanent place in my bookmarks for several years now, his focus on bootstrapping with minimal information-complexity reminds me heavily of efforts like the java4k game programming contest or .kkrieger. Naturally, I am extremely interested in hearing what he had to say at ZuriHac.


…or to use the terminology from Claus Reinke’s thesis, you already have “functions” and “frames” - perhaps his work could be of use to you.

1 Like

Ooh, I love a good solid paper - this one is quite long. It’ll take me a bit to go through it in detail, of course, but I gave it a good enough skim to know it not only be helpful, but also to know that I have I have my own answers to the two major problems posed - external interaction, and managing complexity - and so it will be interesting to see how they mesh with the results of the paper.

This would be what I’d want to focus on. A new compiler toolchain could be centered around providing the best editing experience with first-class debugging and hole-driven development. It would never beat GHC compiled code in terms of performance, but could wind up being more ergonomic than GHCi.


Ben Lynn’s talk has been published:


While we’re in hypothetical “would like to see” for Haskell compilers, I would like to see (and would even pay money for):

  • A Haskell compiler that compiles with CAS out of the box like Unison, that solves a dozen problems related to distribution, recompilation, test suite running, etc.
  • A Haskell compiler that fully embraces the Lisp image in which I can update definitions in place, avoid type erasure so that I can inspect things running live, and for bonus points provide a way to migrate programs live.
  • Haskell with an Erlang runtime i.e. no shared memory, separate GCs per process, supervisors, etc.
  • Haskell with a Lisp like macro system from the beginning.
  • Haskell as a single statically linked self contained binary, with some batteries included, like DrScheme.

I think most of these are hard to do from GHC.

I thought about using Duet to dabble with these ideas. The source code to that is not my favorite, as I lifted most of it from THIH with modifications, I understand it on a superficial level, but it’s the most faithful Haskell implementation I have. Inflex is my “best work” compiler, so its source code is a much higher standard of quality and clarity and test suite than Duet, and I built every part from the ground up, but it’s for a mini Unison-meets-PureScript language for spreadsheets. I thought that I could fairly easily re-skin it as a miniature Haskell, though, and drop the row types from it.

Overall I feel like it’d be fun to have more mini Haskells knocking about that try “Haskell but what if instead” that are hard to try in GHC. Not to say there aren’t others Haskell Implementations Archive · GitHub but they’re all quite old.


I really want this, this would make it so much better!

Ohh god, yea please!


“content-addressable storage” : another buzzword buzz-term for the collection, taking its place alongside “write once, run anywhere” and “orthogonal persistence”.

…and perhaps making some all-new ones:

@atravers I’m not sure where you are going with this. @chrisdone has explicitly added “like unison”. Maybe a reference to 💡 The big idea · Unison programming language helps?

I’m not sure we need to derail everything into nix.


It’s a matter of transitivity:

  1. A Haskell implementation supporting $STORAGE;

  2. $STORAGE is used by $SYSTEM;

  3. $SYSTEM (at that time) had no way of clearing errant content, presumably from its $STORAGE facility.


But almost four decades ago, it was $SYSTEM="operating system"; $STORAGE="virtual memory system" :

(…I missed one - $STORAGE_DEVICE="disc" :-)

Apart from being distributed, has anything substantially changed in those “low-level parts” (of OSs or CASs) since then?

Could Hackett’s macro system (and the associated research) be of any use for that purpose?