Right. I guess I should have emphasized the surface syntax conversaions between Haskell and the new language, while keeping the inner system staying the same. This way we wouldn’t need to bootstrap a new ecosystem. ← I guess I meant a transpiler.
But the real solution is […] dependent types […]
Is that really the case?
If I try to infer OP’s intent: it is the desire to contribute to Haskell ecosystem especially to have another compiler to complement what GHC does to the ecosystem; but at the same time, the fear of the difficulties and slowness for its a old and giant project?
I know I should not provide the n+1th argument for why we should contribute to GHC, but I just wanted to see if I got this correctly.
Yeah. The really short version is that I’m hopeful that another actively developed compiler could help resolve the tension of standardization in the same way that, say, the Dhall standard doesn’t change until multiple implementations implement this or that proposal.
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.
2 Likes
…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.
6 Likes
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.
3 Likes
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.
2 Likes
…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.
@jaror
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.
3 Likes
…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.
3 Likes
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.
8 Likes
4 Likes
I really want this, this would make it so much better!
Ohh god, yea please!
2 Likes