Again: FFI Syntax

[Manuel M. T. Chakravarty]

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