Ecosystem/library support for Wasm/WASI needs a strategy
The addition of WebAssembly as a target comes with an additional OS platform: the WebAssembly System Interface (WASI). As mentioned in #21258 (closed), this platform will require conditional logic in GHC's build system. But a similar issue applies to libraries.
At present we are aware of two widely used packages that expose OS APIs:
unix and
Win32. The unix
package is not available on Windows systems, and the Win32 package
is not available on Unix systems. The ecosystem as a whole knows that
neither of these packages is available on all platforms.
A client package that needs operating-system services can use its own
conditional build-system logic to request either the unix package or
the Win32 package, according to what is available on the target
platform. The question is, what package should be made available the
WASI platform?
WASI is neither POSIX nor Win32. We would like the ecosystem
eventually to become aware of WASI. Ideally, conditional build logic
could discover if it was targeting a WASI platform, and in that case,
there would be a wasi package available for it to depend on.
But at present, no build system or package is aware of WASI, and the
migration path is not clear. Of particular concern is transitive
dependency: If package A depends on B, C, and D, which needs OS
support, expecting the author of package A to migrate package D is
probably not a good plan.
An alternative can exploit WASI's resemblance to a subset of POSIX.
One possible interim tactic would be to pretend that WASI is a flavor
of Unix, and to alter the unix package with C preprocessor
directives that would make it possible to build on a WASI target.
(For a step in that direction, see !205 against the unix
package.) This tactic
offers a choice of how to handle "missing" functionality, such as the
POSIX process model, that is available on POSIX but not WASI:
-
Write stubs for the missing functions such that if any such function is called, a Haskell exception is raised. This choice would allow all client packages to build, but those packages would be subject to unexpected failures at run time.
-
Remove the missing functions from the export lists of the relevant Haskell modules. This choice would eliminate unexpected run-time failures, but compile-time errors could prevent a client package from building. To be prevented from building would be especially annoying to an author who has in mind a use that does not call on the missing functionality.
Should this tactic be adopted, it is not yet clear how the Haskell
ecosystem might eventually be migrated to proper conditional
compilation against an eventual wasi package.