Skip to content
This repository has been archived by the owner on Nov 24, 2022. It is now read-only.

Handle JavaScript FFI syntactic sugar in renamer/typechecker #36

Closed
TerrorJack opened this issue Oct 25, 2018 · 2 comments
Closed

Handle JavaScript FFI syntactic sugar in renamer/typechecker #36

TerrorJack opened this issue Oct 25, 2018 · 2 comments

Comments

@TerrorJack
Copy link
Member

As a sub-issue of #23.

The current way of handling foreign import javascript/foreign export javascript is a bit silly: we process the parsed AST, recognize JSFFI basic types by string, and after converting to our own FFIMarshalState which will later be used at link-time, we rewrite JavaScript FFI to C FFI, so ghc will happily typecheck them and generate relevant cmm code.

The disadvantages are very obvious:

  • Users cannot properly define newtypes to existing JSFFI basic types since we don't recognize them, and newtypes is sort of a standard practice when Haskellers work with conventional C FFI.
  • When we invoke ahc to compile boot libraries using Cabal, if Haskell modules contain JSFFI declarations, linking will fail because the symbols aren't really in any native object file. So, when we need something like asterius-prim which contain common utilities for Haskell/JavaScript interop, it has to be shipped as a home module pasted into every project, instead as a pre-compiled boot package.

There is only one advantage: working with parsed AST is easy, since it's totally context-free, no loading of dependent modules is required, not do we need to learn about TcRnMonad and such.

We should really handle the syntactic sugar in the renamer/typechecker instead, and do better than disguising JSFFI as C FFI in order to make ghc codegen happy. ghcjs implements and uses hooks to type checking foreign decls, and that's a good starting point.

@TerrorJack
Copy link
Member Author

Fixing this turns out to be a harder challenge than expected. I'm keeping this issue open, but before we properly move the JSFFI logic to renamer/typechecker, we'll improve the current hacks a bit:

  • Users can define newtypes to JSVals. They just still need to write JSVals in JSFFI type decls, and manually do the wrapping/unwrapping in order to make the runtime JSVal mappings work.
  • We'll put several types like JSVal, JSString, JSArrayBuffer, etc along with their from/to conversion functions in a real module: Asterius.Types. Users need to import Asterius.Types to make those types available. Also, they no longer need to paste the conversion code around.

@TerrorJack
Copy link
Member Author

This is actually already delivered, so closing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant