Sven Panne <Sven_Panne@BetaResearch.de> wrote,
Simon Peyton-Jones wrote:
[...] I'd go for automatically adding quotes. Acutally, I'd automatically add a '.h' too. Reason: you are really specifying the assembly or package where the function comes from, and that might be useful for linking as well as includes. If the package was called P, the compiler can #include "P.h", and in addition say -lP on its link command. That's less convenient if there's a .h to strip off.
Hmmm, this looks like mixing concepts again. I thought we agreed on the fact that the include part specifies an #include, and nothing else. For "real" stuff things aren't that easy anyway: Include files for larger libraries live in subdirectories (e.g. <GL/gl.h>, <readline/readline.h>), linking a single additional library is seldom enough (e.g. you normally need to link with termcap,too, when you link with (n)curses, linking an X app needs almost a dozen libs on some platforms, etc.), ...
Meanwhile, I agree that it doesn't make sense to specify link information (see my previous post). I have dropped the sentence Moreover, if the external entity has to be obtained from a dynamically loaded library, the library named \gnterm{fname} (plus the appropriate suffix) has to be loaded before any reference to the external entity may be made. from the spec.
So let's simply say: The contents of the include part of extent are implictly wrapped into double quotes iff they don't start with '<' or '"', and no ".h" is appended. Easy rule, doesn't mix concepts, and is readable:
foreign import ccall "static !myproc myinclude.h" myProc :: ...
IIRC, we agreed earlier that we don't want to distinguish between '<' and '"' includes, but regard all of them as '"' includes. The rationale was that we can't generally specify all required includes in the foreign declaration anyway. Therefore, we provide a facility to include a file *custom made* for that binding and nothing else. Unless there is serious opposition to this design, I will leave it as it is. On a related matter, we did not include the `.h' suffix for the name to double as a library archive spec. As this has been dropped now (see above), I prefer to have an explicit `.h'. As SimonM wrote,
I agree: don't make the '.h' implicit. To me it looks much more readable when it's obvious which is the cid and which is the include.
So, I will make the .h suffix mandatory for include files. Cheers, Manuel