Modified proposal for default decls

[malcolm-ffi at cs.york.ac.uk]

> Most notably, Malcolm's latest proposal introduces a new form
> of abstraction (named thing), a bundle of attributes like Gtk or Bzip.
> Another environment for the compiler to manage! Soon people will
> want to export these things and import them elsewhere!    This
> way lies madness.

Ok, so it was a bit of a wild idea.  I quite like it, but I recognise
that it is kind of elaborate and may be a step too far at the moment.

I'm not so much bothered about whether we have a complicated 'foreign
default' thing or not.  In fact, I'm only really personally interested
in being able to specify header files correctly - the very thing you
propose to exclude!

> What is particularly tanatlising is that to a first approximation none
> of this is necessary.  For example, the native code generator is quite
> happy without any of the new stuff now proposed.

So, because one system is clean and clever and doesn't need all this
junk, all the other systems should simply suffer for their ignorant
poverty?  :-)

> c) What is necessary for particular compilers, compiling in a particular
>    way, to generate the right code. 
>
> Therefore we propose that (c) be not part of the FFI standard.

In that case, I'd like you to be completely consistent and remove
'unsafe' from the FFI spec.  nhc98 and Hugs don't need it, so other
compilers shouldn't need it either!  Make it a compile-time option
to GHC, but please don't allow it in the source code.  It is a
compiler-specific option intended *only* to help GHC generate the
right code, and doesn't belong in the standard spec.

Well, I'm not serious, but you have to admit that it _is_ the logical
conclusion of your approach.

> Notice that
> 	c) is essential, but extremely language and compiler specific

I disagree - while it is certainly essential, there is no need for
it to be compiler specific.  That was the whole point of having this
discussion - to establish a standard mechanism.

> *  The "gtk:" part is a concession to (b).  It specifies a C package
>    from which this procedure comes. There is then some
>    compiler-specific mechanism for mapping the name of a C package
>    to the location of its header files and .o file.

How does this idea of mapping from a "package name" like "gtk:"
to a bunch of header and object files differ from the suggestion
that we be explicit in the source code about that mapping with a
'foreign library' decl?  You say it _should_ be compiler-specific:
but why?  That will really cause grief to users who are trying to
write portable code.  And besides, do any compilers currently have
_any_ mechanism to map "gtk:" onto for instance
    #include <glib/glib.h>
    #include <gtk/gtk.h>
    #include <gtk/gtk_extra.h>
?  No?  I thought not.  So why not let's try to develop a common
mechanism that will work with all compilers?

> You may think this is too minimalist, but there are big advantage
> to simple, minimal designs, even if they can't cope with every
> single case.

My worry is that it cannot cope well with the common case.  Don't get
me wrong - I like minimalism.  But my feeling is that punting the
'difficult' stuff off into non-standard compiler-specific extensions
is the opposite of minimal: users who want portability will end up
needing to learn three different mechanisms, not one.

Regards,
    Malcolm