<div dir="ltr">On Tue, Aug 2, 2011 at 21:09, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011:<div class="im">
> But GHC always emit parse error on "javascript" keyword.<br>
><br>
> For now I'm using (abusing) ccall calling convention and simple<br>
> imports works pretty well, but I would like to support<br>
> exports and static/dynamic wrappers. GHC generates C-code to support<br>
> them, and GHCJS should generate Javascript-code,<br>
> but I have no idea how to use GHC API to generate custom (Javascript)<br>
> stubs. Is it possible at all?<br>
<br>
</div>That is certainly not; you'll need to patch GHC's lexer to do that.<br>
But it's all a bit dodgy since this FFI doesn't make sense unless you are<br>
generating Javascript code (which GHC is not.) Maybe someone else can<br>
comment on that. (Perhaps we need fully extensible calling convention<br>
syntax? Hmmm!)<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> I'd like to create ghcjs and ghcjs-pkg tools that will use their own<br>
> directories and package index and will<br>
> not interfere with ghc. Is it possible with GHC API? How can I do it?<br>
<br>
</div>Check out the approach that cabal-dev uses, which is about what you<br>
are looking for here. (Though, handling base packages might be tricky.)<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div>-- <br>brandon s allbery <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available) (412) 475-9364 vm/sms<br>
<br>
</div>