Re: GHCJS

On Wed, Aug 3, 2011 at 8:56 AM, John Lask wrote:

On 3/08/2011 2:10 PM, Brandon Allbery wrote:

...

On Wed, Aug 3, 2011 at 00:31, John Lask  wrote:

...

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.

I guess I'm confused; I thought the current back-end system *was* that kind of pluggable architecture.  I recall a JVM backend being proposed based on it some time back.

my thoughts of pluggable infrastructure include consideration of ffi bindings and library integration as well as command line options i.e. as discussed in this thread with respect of GHC-JS, rather than just backend code generation - i.e. considerations of broader scope than those currently handled.

Yes, I can enumerate following cosideration when developing "non drop-in replacement for current GHC backend": * command line support. Developers should be able to emulate ghc and ghc-pkg to gain cabal support. Another way would be to standatize compiler command line interface in Cabal and to provide command line parsing library with it. * library support. New backend should really behave like stand-alone compiler, rather then GHC * ffi support, custom ffi calling conventions and custom format for call specification, Javascript or JVM will require radically different call specification then simple function-name as used with C-call. * cross-compilation. GHCJS doesn't work properly on 64bit systems. Javascript lacks real integers and we need to emulate them with Javascript bit-operations. But all javascript bit-operations work with 32 bits. To make Javascript code readable and fast we need to make Haskell Int type to be 32bit-integer, but it is imposible on 64bit system. * Built-in desugaring. Some desugaring provided by GHC is backend-specific. For instance string literals are desugared into application of GHC.unpackCString :: Addr# -> String to some address wich points to '\0' terminated C-string. In GHCJS we better provide our own desugaring, then add terminating '\0' to strings to emulate C-string with Javascript-strings. -- Victor Nazarov