[Dream] Toward another compiler?

[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?