GHCJS

[Victor Nazarov]

On Wed, Aug 3, 2011 at 11:30 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> Victor
>
> GHC is supposed to be extensible, via its API, so your questions are good ones.  However, there are things that that the API doesn't support, or supports badly, so it is not cast in stone.  Please suggest improvements -- and better still implement them. GHC evolves largely in response to your suggestions and help.
>
> In particular I don't think anyone has implemented a new back end via the API (rather than by building it into GHC itself) before.  So this is good.  It would be cool to have a compiler that behaved as if it had a JavaScript backend built in, but was actually built in a modular way on the API. Then people could use that as a model to build new back ends.
>
>
> I imagine that your general plan is:
>  - use the GHC API to parse Hasekll, typecheck it, optimise it
>  - finishing with a [CoreBind] of optimised definitions
>  - then use your own code generator to convert that [CoreBind] into JavaScript

Yes, I'm doing it, but I'm moving slightly fearther

- I convert [CoreBind] to [StgBind] through GHC API.
- then convert StgBindings to Javascript.

>
> | == Command line interface ==
> | 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.
>
> So perhaps that's the problem. parseDynamicFlags could perfectly well simply return any un-recognised flags. Indeed, I thought it did just that -- it certainly returns a list of un-consumed arguments.  If it doesn't perhaps that's a bug.

parseDynamicFlags returns un-consumed arguments if they are something
like filenames, but it throws error if un-consumed argument starts
with dash.

>
> | == Foreign Function Interface ==
> |
> | What I want is to provide FFI for Javascript, But GHC doesn't allow to
> | extend FFI declaration syntax.
> | I'd like to create some new FFI calling convention ("javascript") like this:
> |
> | foreign import javascript "alert"
> |   jsalert :: Ptr JSString -> IO ()
>
> OK, so this is harder.  Presumably you want to use an *unmodified* Haskell parser to parse the Haskell programs. Adding *syntactic* extensions is therefore somewhat invasive:
>        - change the lexer
>        - change the parser
>        - change the HsSyn data structure
>        - change every function that traverses HsSyn
>
> However in this particular case maybe things are not so bad.  I believe that perhaps *all* you want is to add a new calling convention. See ForeignImport in HsDecls, and CCallConv in ForeignCall.  Simply adding a new data constructor to CCallConv, and lexing the token for it, would not be too bad.  We could possibly add that part to the mainline compiler. The compiler would largely ignore such decls, and they'd just pop out at the other end for your back end to consume.

This would be cool. I will try to provide patch to add all calling
conventions that backend implementors can use.
But GHC should report errors about unsupported calling conventions
sometime during compilation when should it?

>
> There might be complications -- see DsForeign in particular -- but I expect they'd be minor.
>
> | 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
> | them, and GHCJS should generate Javascript-code,
> | but I have no idea how to use GHC API to generate custom (Javascript)
> | stubs. Is it possible at all?
>
> Well, GHC generates the stub code in its code generator, doesn't it?  If you don't call the code generator, because you are using yours instead, then it'll be up to you to generate the stub code, no?

I can access ForeignStubs datatype, but I think it already have
generated C-code in it, havn't it? What step during compilation I
should generate stubs on?

-- 
Victor Nazarov