jvlask at hotmail.com
Wed Aug 3 06:31:24 CEST 2011
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:
>>> 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?
>> 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
>> 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
More information about the Glasgow-haskell-users