... | ... | @@ -35,6 +35,7 @@ Medium term (GHC 9.10): |
|
|
- FFI: "inlined" foreign imports (JS syntax with named argument placeholders)
|
|
|
- Feature: profiling (CC, eventlog, ticky-ticky, etc.)
|
|
|
- GHCi: GHCi support (including debugger)
|
|
|
- Milestone: ensure that [ghcjs-dom](https://hackage.haskell.org/package/ghcjs-dom) works with the JS backend (no missing feature)
|
|
|
|
|
|
Long term:
|
|
|
- Support for C-sources: idea is to compile via Emscripten and to automatically generate glue code.
|
... | ... | @@ -90,7 +91,7 @@ TODO: document current GHCJS and Asterius interfaces |
|
|
|
|
|
### What is the plan for handling the various C bits in base/text/bytestring/etc.? Specifically, has there been any motion on discussions with upstreams regarding upstreaming the Javascript implementations?
|
|
|
|
|
|
We plan to propose patches for these libraries. We can use CPP to condition JS specific code to `HOST_ARCH=javascript` and similarly in `.cabal` files (`arch("javascript")`).
|
|
|
We plan to propose patches for these libraries. We can use CPP to condition JS specific code to `HOST_ARCH=javascript` and similarly in `.cabal` files (`arch("javascript")`).)
|
|
|
|
|
|
### Will GHC need to be aware of the system's Javascript interpreter (e.g. know the path to nodejs)? Presumably yes as we will at very least need to know how to start `iserv`.
|
|
|
|
... | ... | |