[Dream] Toward another compiler?

[jhenahan]

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

[AntC2]

@jaror

But the real solution is not …, but rather dependent types

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.

[atravers]

@jhenahan

Could Haskell-the-language evolve from declarative to denotative?

…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…)

---

@jaror

Hopefully the recordings [of Ben Lynn’s talk] will be published soon.

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

[blamario]

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.

[jhenahan]

@blamario

completely new runtime supporting massively parallel or distributed execution

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.

[turion]

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.

[atravers]

@jhenahan

NB: I’m less interested in hearing the nth argument for “you should just work on GHC instead”, since this is particularly a thread to centralize and chew on some other points in the space, and how I choose to burn the back 9 of my creative life is likely to include more contributions to GHC, anyway. You’re welcome to write the argument in this thread, of course.

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

@jhenahan

I have no performance goals and no timetable, so unreasonable dreams like “TRex 2” or “first class Backpack/other module system” or what-have-you could be discussed.

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

[turion]

@atravers

…and now someone seems to have done so

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

[ApothecaLabs]

@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.

[atravers]

@ApothecaLabs

[…] a teeny lambda calculus with a module system […]

…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.

[ApothecaLabs]

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.

[jmorag]

@blamario

bottom-up design for integration with novel development tools

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.

[jaror]

Ben Lynn’s talk has been published:

Ben Lynn on "MacGyver's Haskell Compiler" @ZuriHac2023

[chrisdone]

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.

[Kleidukos]

#21578: [Discussion] Erlang-style processes in the RTS · Issues · Glasgow...

[angerman]

@chrisdone

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.

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

@chrisdone

Haskell with a Lisp like macro system from the beginning.

Ohh god, yea please!

[atravers]

CAS out of the box […]

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

[…] that solves a dozen problems related to distribution, recompilation, test suite running, etc.

…and perhaps making some all-new ones:

Using unsafePerformIO safely?

Here’s a concrete example of why I don’t like pretending that anything that interacts with the OS is “pure”: At work we have a Nix-based build system. It “should be” pure, since Nix is reproducible. However, it sometimes calls out to external hardware which is transiently broken, caching “hardware did not respond” into our build results, and with no way of purging it. There’s no direct analogue of that in Haskell, but it really makes me cautious of “pure” APIs that call out to the OS, and I wou…

• Compositional podcast - A content addressable store for Nix with Théophane Hufschmitt - Links - NixOS Discourse (2020)

[angerman]

@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.

[atravers]

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.

…here, $SYSTEM=Nix; $STORAGE=CAS.

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

(page 18 of 31)

It would also be possible to use the disc to implement a virtual memory system, which retains the integrity of the heap when the system is powered down. This would allow objects to be “filed” simply by holding onto them as data structures: a large virtual memory would ensure that they eventually migrated onto disc, and the result is, to a far greater extent, a “functional” program. My instinct, however, is to be wary of this approach for the following reasons:

1. It demands far more implementation effort “beneath” the level of functional programming. It is the low level parts of operating systems whose semantics are most in doubt and where hidden bugs are most harmful: this is where functional programming is needed most!

2. It seems more liable to disaster from some hidden bug in the operating system. Merely discarding a pointer might discard the filing system, requiring recovery in some manner “outside” the operating system.

A New Scheme for Writing Functional Operating Systems, (1984).

(…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?

[atravers]

@chrisdone

Haskell with a Lisp like macro system from the beginning.

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