Updates to FFI spec: hs_init() & friends

[Manuel M T Chakravarty]

"Simon Marlow" <simonmar at microsoft.com> wrote,

> > >> - Changes to hs_init
> > >> 
> > >> http://www.mail-archive.com/ffi@haskell.org/msg00539.html

This proposal doesn't work with these types IMHO.  The
reason is that you won't know which arguments to pass to

  hs_set_hs_argv   (int argc, char *argv[]);

Typically, the command line will contain a mix of arguments,
where some meant for the Haskell system (in GHC, +RTS stuff)
and some for the application.  The application has no way to
distinguish the two.  So, the idea with 

  hs_init    (int *argc, char **argv[]);

was that the Haskell system grabs all it's arguments and
*removes* them from argv (hence, the double indirection).
This is sort of set up is essential when there are mulptiple
libraries that require to get at some command line arguments.

Moreover, although I understand John Meacham concern, I
don't see how it is addressed by the proposed change to the
interface.  hs_set_hs_argv() still may only be called once.
Wherever, this is done, we could just have called
hs_init().  And do away with all the extra calls to the
"new" parameterless hs_init().

Further to John Meacham's concern, the only solution that I
see is to allow multiple calls to hs_init() and hs_exit()
and place the burden of keeping track of multiple
initialisations onto the Haskell system.  No change to the
function prototypes is needed to implement this, only a
change of the specification of the semantics (namely,
permitting multiple calls).

So, my proposal is to

* permit multiple calls to hs_init() and hs_exit() (the
  number of calls must match of course),

* command line arguments specified in the second and
  following invocations to hs_init() are ignored, and

* both arguments to hs_init() may be NULL (to indicate the
  absence of arguments).

The second point is necessary to keep the implementation on
the Haskell side reasonably straight forward.

I think, we also need to say something about the timing of
hs_set_argv() and calling getProgName and getArgs.  I'd say,
if hs_set_argv() is used at all, it must be before the first
call to getProgName and getArgs (otherwise, the system
behaviour is undefined).

Objections?

> > > I am ok with that.  Currently, there is a problem with the version
> > > that is in the spec and GHC in that GHC requires an extra argument
> > > to initialise modules.  So, it all depends a bit on how far SimonM
> > > thinks its implementable.
> > 
> > Hugs doesn't have anything resembling hs_init at the moment so I can't
> > say for sure.  I think it can be done as a thin layer on top of the
> > the existing spec though so I don't think it's that hard.
> 
> Perhaps on GHC you should be required to "register" the top module in
> your program first, maybe something like
> 
> 	registerModule(__stginit_Main);
> 
> that way you can register multiple modules (which isn't possible at the
> moment, you have to have another module which imports all the others).

So, registerModule() would be a GHC-specific extension to
the FFI API?

Manuel