GHCJS

Brandon Allbery allbery.b at gmail.com
Wed Aug 3 03:49:57 CEST 2011


On Tue, Aug 2, 2011 at 21:09, Edward Z. Yang <ezyang at mit.edu> wrote:

> Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011:
> > But GHC always emit parse error on "javascript" keyword.
> >
> > 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?
>
> That is certainly not; you'll need to patch GHC's lexer to do that.
> But it's all a bit dodgy since this FFI doesn't make sense unless you are
> generating Javascript code (which GHC is not.)  Maybe someone else can
> comment on that. (Perhaps we need fully extensible calling convention
> syntax? Hmmm!)
>

If making it a backend isn't acceptable then it's a bit of a lost cause; I'd
expect it to be a backend, with backend hooks to support various -f* options
(probably already exists) and the foreign syntax changed from expecting a
keyword to expecting an identifier and optional parenthesized identifier
list (the same syntactic category as import and export lists, "deriving"
clauses, etc.), and that would be passed to the backend.


> > 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?
>
> Check out the approach that cabal-dev uses, which is about what you
> are looking for here.  (Though, handling base packages might be tricky.)
>

And I'd point out that this sounds similar to another recently reported
shortcoming of ghc-pkg (mentioned in the context of cabal's dependency
calculations but I miscall the details at the moment).  I would expect JS
packages to register a dependency on a version of base specific to the JS
backend, and that dependency would prevent libraries using the standard base
package from being considered.

-- 
brandon s allbery                                      allbery.b at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110802/670d5c5d/attachment.htm>


More information about the Glasgow-haskell-users mailing list