Yeah, that was the first question on my mind too: "WTF is GHC?". A quick Google search reveals that it's the Glasgow Haskell Compiler. Maybe it makes sense to expand that in the title?
Haskell is a language standard, and GHC is an implementation of that standard. It may be the only one (not sure the status of Hugs, another implementation), but that's the difference, I believe.
Is it just me or does it seem nonsensical that TH splices are compiled to WASM then executed with a WASM interpreter rather than just being interpreted natively by GHC like done with GHCi? Would also fix the weird situation with running git inside splices not working.
In general, you must run TH on the target platform for it to be correct. Otherwise, you may generate code that only works on your host (it isn't impossible for TH output to be platform-specific especially since it can do IO)
But sometimes it might want to run on the host still (e.g. there are tools out there that generate C bindings that use platform-specific things like sizes and alignments)
If we had pure TH, then at least that could run in wasm. That would be nice.
But idk - I cross-compile Haskell heavily in my free time and I don't mind the external interpreter stuff.
This is pretty cool. If I wanted to compile some old Haskell app, that was built with GHCJS, to WebAssembly should I use this unreleased branch of GHC or go for (seemingly) batteries included Asterius?
12 comments
[ 4.1 ms ] story [ 40.0 ms ] threadIf we had pure TH, then at least that could run in wasm. That would be nice.
But idk - I cross-compile Haskell heavily in my free time and I don't mind the external interpreter stuff.
IMO, ideally, pure TH wold be completely platform independent. But running in a standardized VM is a close second place.
Anyway, I never realized those bidings were created with TH.
Edward Z Yang has a canonical post on this: http://blog.ezyang.com/2016/07/what-template-haskell-gets-wr...