GHCJS

[John Lask]

What is really required is a "pluggable" back-end infrastructure - 
whereby various back-ends could be maintained (or not) at the discretion 
of their originators and separate to the official ghc back-ends.

Ideally pluggable back-ends would be installable as packages.

such infrastructure, I would hazard a guess, would require considerable 
thought to design properly.

On 3/08/2011 11:19 AM, Brandon Allbery wrote:
> 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.
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users