Short version: the simple answer is “yes,” but the better answer is “eh.”
Here’s the thing: GHC already has a fairly agnostic way to compile it to different platforms. It’s not particularly well documented or separated, but it’s there. So if you wanted to do something for GHC, probably the simplest approach would be to (a) document it a bit better and make the interface more cleanly defined, and (b) write documentation on how to link a generated .o file to the libc and OS layer for your target system.
You could maybe claim victory at this point, and call it
The next step would be to modify the build system and compiler pipeline to allow you to determine the target and link in the runtime at the last possible moment. My intuition is that this step is going to mire you in a world of hurt, and could possibly require you to go all the way towards creating a retargetable, cross-compiling GHC. There will likely be committees (official or self-nominating).
You could certainly claim victory at this point, but I wonder how much adoption you’d get.
The next step would be to rejigger all the tools (Cabal, at the least) to support your new workflow. There are a few long-standing tickets to this effect; for example, this one.
At this point, you might get a few early adopters, like the HaLVM.
Once you’ve done all that, you’ve got your toolchain ready to go, so now all you have to do is get Haskell program and library authors to change the way they write programs. Of course, we’re facing this problem with the HaLVM, anyways, but I suspect a
ghc-freestanding is going to be possibly worse. To understand, consider something simple, like a web server. When the author of the web server wants to use networking functions, they will need to be customized based on the final platform, because not all platforms export the same network interfaces. As an example, the rumpkernel exports POSIX, but Solo5 only exports a network card interface. Can you bridge the gap between these two at link time? Similarly, file systems: where do you store files, in what format, using what drivers or libraries?
If you can solve this problem, you’d be my hero. I’m hoping the Backpack stuff helps us down this road.
With the HaLVM, we’ve side-stepped a number of these issues for awhile by basically ignoring the rest of the Haskell community. This approach has allowed us to make progress around our own herky/jerky timelines, and kept us out of any number of design, review, and pull request quagmires. The downside – which is 100% a completely reasonable consequence of my decision to run the HaLVM as an independent fork of GHC – is that, of course, we’re not really integrated into the mainline development practices or tooling for GHC.
Anyways, that’s the long answer to your question. Again, the short answer is that you could certainly perform the base technical work of creating a
ghc-freestanding; the difficult part would be figuring out how to make it easy to use, integrated into mainline toolsets, and get library authors to think about this retargetability when they develop their libraries. Finally, we are actually looking at doing this sort of thing with the HaLVM, but in a very limited way: in HaLVM v3.0, we’d like to be able to create retargetable bases for unikernels, specifically. So you could easily recompile a Xen unikernel into a KVM unikernel. But we would not be tackling the larger problem of including things like Windows into this mix.