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 -
>>> 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
>> 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
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 then simple function-name as used with C-call.
* cross-compilation. GHCJS doesn't work properly on 64bit systems.
Haskell Int type to be 32bit-integer, but it is imposible on 64bit
* Built-in desugaring. Some desugaring provided by GHC is
backend-specific. For instance string literals are desugared into
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
More information about the Glasgow-haskell-users