GHCJS

Victor Nazarov asviraspossible at gmail.com
Wed Aug 3 12:33:18 CEST 2011


On Wed, Aug 3, 2011 at 8:56 AM, John Lask <jvlask at hotmail.com> wrote:
> On 3/08/2011 2:10 PM, Brandon Allbery wrote:
>>
>> On Wed, Aug 3, 2011 at 00:31, John Lask<jvlask at hotmail.com>  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



More information about the Glasgow-haskell-users mailing list