... | @@ -16,13 +16,13 @@ Merging upstream whatever can be useful/tested independently of the rest. |
... | @@ -16,13 +16,13 @@ Merging upstream whatever can be useful/tested independently of the rest. |
|
|
|
|
|
Otherwise maintain a separate branch (`wip/javascript`) into which MRs can be merged until we feel that the entire story is well-enough developed to be confidently merged upstream.
|
|
Otherwise maintain a separate branch (`wip/javascript`) into which MRs can be merged until we feel that the entire story is well-enough developed to be confidently merged upstream.
|
|
|
|
|
|
### How does the JS backend interact with the on-going plans to make GHC runtime retargetable? Is the current plan for JS to merge before runtime retargetability, therefore requiring the user to build a new compiler to use the backend?
|
|
### How does the JS backend interact with the on-going plans to make GHC runtime retargetable? Is the current plan for JS to merge before runtime retargetability, therefore requiring the user to build a new compiler to use the backend?
|
|
|
|
|
|
There is no interaction. Currently even with GHCJS we need two compilers (one for the JS target and one for the host) so having a single multi-target compiler isn't mandatory.
|
|
There is no interaction. Currently even with GHCJS we need two compilers (one for the JS target and one for the host) so having a single multi-target compiler isn't mandatory.
|
|
|
|
|
|
In the long term, having the ability to select the backend without rebuilding the compiler would probably improve the user experience though.
|
|
In the long term, having the ability to select the backend without rebuilding the compiler would probably improve the user experience though.
|
|
|
|
|
|
### Is the expectation that the JS backend passes the entirety of the testsuite; if not, will it be a separate testsuite way?
|
|
### Is the expectation that the JS backend passes the entirety of the testsuite; if not, will it be a separate testsuite way?
|
|
|
|
|
|
It should be a separate testsuite way as there are some features that are not expected to pass (e.g. support for `compact`).
|
|
It should be a separate testsuite way as there are some features that are not expected to pass (e.g. support for `compact`).
|
|
|
|
|
... | @@ -30,11 +30,11 @@ It should be a separate testsuite way as there are some features that are not ex |
... | @@ -30,11 +30,11 @@ It should be a separate testsuite way as there are some features that are not ex |
|
|
|
|
|
Yes. Not necessarily in the `rts/` directory (perhaps `rts-js` ?) Currently GHCJS loads its JS RTS from its collection of JS files ("shims") we don't want to upstream this feature. Instead we would like to make the JS RTS a proper package/unit.
|
|
Yes. Not necessarily in the `rts/` directory (perhaps `rts-js` ?) Currently GHCJS loads its JS RTS from its collection of JS files ("shims") we don't want to upstream this feature. Instead we would like to make the JS RTS a proper package/unit.
|
|
|
|
|
|
### Is the RTS going to support the full feature surface supported by GHC's C RTS?
|
|
### Is the RTS going to support the full feature surface supported by GHC's C RTS?
|
|
|
|
|
|
Probably not (e.g. no plan for `compact` support afaik). Do we have a list of GHC's C RTS features that we could use to indicate supported features?
|
|
Probably not (e.g. no plan for `compact` support afaik). Do we have a list of GHC's C RTS features that we could use to indicate supported features?
|
|
|
|
|
|
### How are "ways" interpreted in the context of Javascript? For instance, "dyn" makes little sense in this context. Depending upon the RTS implementation, the same might be said of `-debug`, `-threaded`, and `-eventlog` (cf #20741)
|
|
### How are "ways" interpreted in the context of Javascript? For instance, "dyn" makes little sense in this context. Depending upon the RTS implementation, the same might be said of `-debug`, `-threaded`, and `-eventlog` (cf #20741)
|
|
|
|
|
|
GHCJS also has different RTS "ways" (e.g. to enable some assertions). Additionally we could imagine generating different code for different targets (NodeJS, browsers, etc.).
|
|
GHCJS also has different RTS "ways" (e.g. to enable some assertions). Additionally we could imagine generating different code for different targets (NodeJS, browsers, etc.).
|
|
|
|
|
... | @@ -42,13 +42,13 @@ Currently GHCJS just ignore "ways" (e.g. it returns the same code for both objec |
... | @@ -42,13 +42,13 @@ Currently GHCJS just ignore "ways" (e.g. it returns the same code for both objec |
|
|
|
|
|
As we have workarounds, we don't plan to work on #20741 until we have a usable JS backend. But we might work on it after it's done. Any help or feedback on #20741 is welcome.
|
|
As we have workarounds, we don't plan to work on #20741 until we have a usable JS backend. But we might work on it after it's done. Any help or feedback on #20741 is welcome.
|
|
|
|
|
|
### What are we going to do about GHC's many native-code-centric flags (e.g. -fPIC, -shared, -msse2). Will these be errors if used when targetting Javascript?
|
|
### What are we going to do about GHC's many native-code-centric flags (e.g. -fPIC, -shared, -msse2). Will these be errors if used when targetting Javascript?
|
|
|
|
|
|
There are currently ignored by backends that don't use them. We could probably detect and report their use during command-line flags validation but it is out of the scope of the JS backend implementation.
|
|
There are currently ignored by backends that don't use them. We could probably detect and report their use during command-line flags validation but it is out of the scope of the JS backend implementation.
|
|
|
|
|
|
### Are there plans to support the Ticky-Ticky profiler? Cost-centre profiling?
|
|
### Are there plans to support the Ticky-Ticky profiler? Cost-centre profiling?
|
|
|
|
|
|
I don't see why we wouldn't support them.
|
|
I don't see why we wouldn't support them (cost centre profiling has been supported in GHCJS before, but a few pieces are broken, ticky-ticky profiling hasn't been supported yet)
|
|
|
|
|
|
In addition, we could also support JS specific debugging to harness browser's debugging tools.
|
|
In addition, we could also support JS specific debugging to harness browser's debugging tools.
|
|
|
|
|
... | @@ -60,11 +60,11 @@ Perhaps worth a ghc-proposal. |
... | @@ -60,11 +60,11 @@ Perhaps worth a ghc-proposal. |
|
|
|
|
|
TODO: document current GHCJS and Asterius interfaces
|
|
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?
|
|
### 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_OS=ghcjs` and similarly in `.cabal` files.
|
|
We plan to propose patches for these libraries. We can use CPP to condition JS specific code to `HOST_OS=ghcjs` and similarly in `.cabal` files.
|
|
|
|
|
|
### #21078 lists "one-shot JS code generator" as one of its tasks. I suspect I am misunderstanding but my first interpretation of this phrase suggests that `--make` mode will not be supported.
|
|
### #21078 lists "one-shot JS code generator" as one of its tasks. I suspect I am misunderstanding but my first interpretation of this phrase suggests that `--make` mode will not be supported.
|
|
|
|
|
|
We do plan to support `--make` mode. It's just that one task to get there is first to support compiling a single module into a single `.o` without any linking step, which we have summarized as "one-shot".
|
|
We do plan to support `--make` mode. It's just that one task to get there is first to support compiling a single module into a single `.o` without any linking step, which we have summarized as "one-shot".
|
|
|
|
|
... | | ... | |