Sven Panne <Sven_Panne@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