Updates to FFI spec: hs_init() & friends

Manuel M T Chakravarty chak at cse.unsw.edu.au
Wed Sep 11 03:00:33 EDT 2002

Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> wrote,

> Alastair Reid <alastair at reid-consulting-uk.ltd.uk> writes:
> > > So, my proposal is to:
> > > [...]
> > 
> > I think only GHC implements anything like this (correct me if wrong,
> > Malcolm) and they haven't used it in the way John Meacham is
> > interested in.
> At the moment, nhc98 provides a routine
>     void haskellInit (int argc, char **argv)
> which collects the command-line args intended for (1) the nhc98 runtime
> system, and (2) the response to System.getArgs.  It does not strip any
> arguments from the given set, on the basis that the calling C routine
> may be interested in the same arguments that nhc98 is interested in.
> Also, if the controlling C routine wants to alter the argument
> set before Haskell sees it, that is perfectly catered for by this
> interface.

I am sorry, but I really think that this interface is too
restrictive.  My opinion here stems less from using Haskell
for implementing C libraries and more from using and
implementing C libraries (in C) that need to get at some
library-specific arguments.  Here some requirements:

* In general, hs_init() must be able to remove arguments.
  Some Haskell systems - eg, GHC - will allow arguments to
  the runtime that just don't make any sense to the user
  program and/or other libraries.

* We must design the interface such that it does not place
  any restriction on the order in which libraries are
  initialised.  The reason is that the libraries themselves
  may put constraints in the order of initialisation, which
  may conflict with any artificial ordering that we require
  by a less flexible interface.

* For mostly transparent Haskell libraries, it is not
  sufficient that the C program can alter the arguments
  before Haskell sees it, but the C program may expect that
  the library (incidentally) implemented by a Haskell
  program already strips all arguments that are present
  because the library is implemented in Haskell (eg, again
  arguments to the RTS).


More information about the FFI mailing list