GitLab

Giving GHC a proper JavaScript backend has been discussed before (#7496 (closed), #7933 (closed)) but it has never been done. We propose to do it by adapting code from GHCJS. Maintaining GHCJS out of GHC's tree is a lot of work that isn't sustainable. Moreover having a proper JS backend in GHC would make the compiler much easier to setup for end users and to maintain/enhance for GHC(JS) devs.

GHCJS's code currently relies on GHC 8.10 branch and there are several things that need to be adapted or removed. E.g. shims (JS code to replace C code) should be upstreamed in hackage libraries, we don't need to use GHC's hooks anymore, plugin support should be properly added (#20964, #14335), etc.

Hence we plan to add features one by one as if we were implementing the backend from scratch, except that we will copy/adapt a lot of code from GHCJS so the process should be faster and we already know that GHCJS's code works.

• Wiki page: https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend
• most up-to-date GHCJS branch: https://github.com/ghcjs/ghc/tree/ghc-8.10-ghcjs
  • status: https://github.com/ghcjs/ghc/blob/ghc-8.10-ghcjs/README.GHCJS.md
• green GHCJS testsuite work: https://gitlab.haskell.org/ghc/ghc/-/commits/wip/jdm/ghcjs-testsuite/

Things to do (refine as needed as progresses are made):

• JavaScript code generator

  • JavaScript pretty-printer

    • [staging] implemented in GHC.JS.* modules
    • [todo] Use FastString more instead of ShortText
    • [todo] Open MR

  • STG to JS compiler

    • [staging] Implemented in GHC.StgToJS.* modules
    • [todo] more documentation: haddocks, design notes
    • [todo] Update MR !7573 when documentation is done

• RTS

  • DerivedConstants

    • [done] make deriveConstants support js platform (static constants)
    • [done] MR: !7585 (merged)

  • Modify build system to build rts-js instead of C rts

    • [todo] remove make build system :-)
    • [todo] adapt Hadrian

  • Embed RTS JS code into rts unit

    • [todo] use Cabal's js-sources or convert js files into JS .o files?

  • Generated JS code

    • [todo] migrate JS code generation from GHCJS
    • [todo] decide how to handle it: when building the rts unit (GHC could inject it) or at rts link time

• Linker

  • [staging] Support .o deserialization (GHC.StgToJS.Object)
  • [todo] Support linking into archives
  • [todo] Support linking into executables? (what does it mean for JS backend)
  • [todo] Support linking the RTS (see RTS section above)

• FFI

  • Design

    • [todo] Design user interface that works with wasm backend too

  • Foreign imports

    • [todo] Support inlined JS code

  • Support JS managed values (JSVal#/OpaqueRef#)

    • [todo] Add RuntimeRep for JS managed values #21142 !7577

  • Foreign exports

    • [todo] support calling into haskell code (sync/async)

  • C sources (FFI ccall conv)

    • [todo] use external toolchains (emscripten, wasi-sdk...) to compile them into JS/wasm
    • [todo] generate wrappers for ccall ffi imports to deal with impedance mismatch between heap representation, argument representation, etc.

• Boot libraries

  • [todo] add CPP to make them usable on JS platform

• Template Haskell

  • [todo] adapt GHCJS' thrunner to use bytecode

• Testsuite

  • [todo] fix support of cross-compilers
  • [todo] disable some tests (predicate on JS platform)

• Documentation

  • [todo] user guide
  • [todo] design notes (heap representation, etc.)

Our team at IOG is committed to do this but any help and feedback is appreciated.