Removing GHCJS from Cabal

Announcements
1

GHCJS was upstreamed and merged as the JavaScript backend to GHC in Dec 2022 and released with GHC 9.6.

Cabal has a long deprecation process but with GHCJS already moved into GHC, it is Cabal that is lagging behind, isn’t it?

Last month a draft pull request landed to validate the GHC JavaScript backend, but this is waiting for the next batch of GHC releases. It doesn’t look like the GHCJS-specific logic in Cabal is much tested aside from one GHCJS-specific test. Cabal’s GHCJS module is pretty much a stranded duplicate of Cabal’s GHC module that misses out on some GHC-specific maintenance changes.

How should we look at GHCJS, as separate from GHC or more of a temporary fork?

The JavaScript backend in GHC obsoletes ghcjs/ghcjs, doesn’t it? This repository’s default branch and the most recently active branch, ghc-8.10, was last updated 4 years ago. Of the 185 forks of ghcjs, are any moving ahead, still active or need Cabal updates?

Cabal has a 3-year support Window for GHC releases. Does anyone object if we deprecate GHCJS support immediately and remove it in the next major release?

  • Has your team already moved to the native GHC JavaScript backend? If so, is GHCJS already entirely obsolete for you?

  • Are there production uses of GHCJS that cannot yet migrate to the GHC JavaScript backend? Can these activities continue with released versions of Cabal and cabal-install? Will they be stranded if GHCJS is not supported in newer versions of Cabal and cabal-install?

  • Are there any problems with the GHC’s JavaScript backend when used with Cabal that we need to resolve before removing GHCJS?

Please let us know your thoughts, concerns, or objections either here or on the issue for closing Cabal’s GHCJS support window (that we may convert to a discussion).

11 Likes
2

Before posting here, I asked around among some of the people who worked on the upstreaming and some who maintain libraries targeting the JavaScript and WASM backends. Nobody objected to Cabal dropping GHCJS. The points they made were:

  • The JavaScript backend should be at feature parity with GHCJS for most use cases. Some things were reimplemented and may not be exactly equivalent to what GHCJS did and some obscure features, such as dumping the list of FFI function names used, were dropped but could easily be added back if someone needs them.

  • Anyone still using GHCJS can use an older Cabal but really it would be better to improve the JavaScript backend to their needs.

  • Libraries that started out on GHCJS now target the latest GHCs for the JavaScript and WASM backends and keep GHCJS around, if at all, only for internal testing and comparison.

  • Some people keep the old GHCJS in their codebases because of a dead code elimination pass that was disabled in GHCJS 8.10 and isn’t in the upstreamed JavaScript backend, so payloads are larger.

  • On the GHC side, js-sources and GHC plugins don’t yet work with the WASM backend.

Stack fully removed GHCJS support back in 2020.

8 Likes
3

Speak now or forever hold your peace!

6 Likes