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<ezy...@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@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
