asviraspossible at gmail.com
Wed Aug 3 01:12:55 CEST 2011
I'm a maintainer and creator of GHCJS tool .
There is a great interest to the project, but there have been little
I'm considering the future of it and I'd like to get some advices or
suggestions from GHC maintainers.
push it into GHC mainline.
Besides it was expressed several times  that GHC HQ doesn't want to
support another backend
which brings lots of interoperability problems with it.
Since then GHCJS switched to GHC API. For now code generation works
But I have many problems that I'd like to solve and I'm not sure if it
is feasible using GHC API,
== Command line interface ==
I'd like to reproduce GHC command line interface for GHCJS tool. For
now I'm using something like this:
main :: IO ()
do args <- getArgs
defaultErrorHandler defaultDynFlags $ runGhc (Just GHC.Paths.libdir) $
do sdflags <- getSessionDynFlags
(dflags, fileargs, _) <- parseDynamicFlags sdflags (map noLoc args)
_ <- setSessionDynFlags dflags
let fileargs' = map unLoc fileargs
targets <- mapM (flip guessTarget Nothing) fileargs
This works, but I'm not allowed to parse some custom flags used by
GHCJS code and not by GHC API.
ParseDynamicFlags throws UsageError if it encounters some unknown flags.
What can I do to extend GHC's command line arguments' syntax with some
custom arguments used by GHCJS?
I can parse arguments myself
and throw the rest of them to parseDynamicFlags, but GHC's flags are
really complicated and I'm not aware
of any argument parsing library that can be used to filter out some
specified flags and return the rest GHC's flags untouched.
== Foreign Function Interface ==
extend FFI declaration syntax.
jsalert :: Ptr JSString -> IO ()
For now I'm using (abusing) ccall calling convention and simple
imports works pretty well, but I would like to support
exports and static/dynamic wrappers. GHC generates C-code to support
stubs. Is it possible at all?
== Packages support ==
It will be very handy if users can use Cabal to install and build
packages with GHCJS.
It should work if I replicate ghc and ghc-pkg command line interface,
but remaining problem is that
package index and package directories will be shared with GHC,
I'd like to create ghcjs and ghcjs-pkg tools that will use their own
directories and package index and will
not interfere with ghc. Is it possible with GHC API? How can I do it?
More information about the Glasgow-haskell-users