You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 24, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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 ownFFIMarshalState
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:
newtype
s to existing JSFFI basic types since we don't recognize them, andnewtype
s is sort of a standard practice when Haskellers work with conventional C FFI.ahc
to compile boot libraries usingCabal
, 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 likeasterius-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.
The text was updated successfully, but these errors were encountered: