Again: FFI syntax

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Tue May 29 09:32:33 EDT 2001


Sven Panne <Sven_Panne at BetaResearch.de> wrote,

> "Manuel M. T. Chakravarty" wrote:
> > Now that we require the include file to have the suffix
> > `.h', the declaration should be unambigious without '!'.
> > Or do I overlook anything?
> 
> To be exact, we don't require a `.h' suffix, we just don't add `.h' stealthily.
> And if I read the ISO C spec correctly, this suffix is not required by it, so
> things are still ambiguous. But again, other people on this list would probably
> say: You have to write your own header file anyway, so you can give it a name
> including the `.h' suffix.  :-P

Other people?  Me!  Requiring a .h prefix solves a problem
and doesn't really complicated anything for users.

> Just to restate my position: I'm against *always* wrapping the header file name
> in double quotes, unless
> 
>    #include "foo/bar.h"
> 
> implies
> 
>    #include <foo/bar.h>
> 
> if the first form is not found. I'm not sure about this, although it's guaranteed
> the other way round IIRC. It's a little bit awkward being forced to write a
> custom header when a system supplied one is the only thing one wants. But this
> is not a topic of paramount importance, so I'll probably surrender if there's
> no support for my position...   :´-(    ;-)

The if the first form is not found is not feasible, I think,
because the Haskell compiler will have to commit to one when
generating C code.

I think, it is awkward to quote the quotes, but if there is
a general feeling that we should allow optional '<' '>'
around the header files to mean `use the system search
path', that's ok with me.

Cheers,
Manuel




More information about the FFI mailing list