Modification to foreign import/export

[Marcin 'Qrczak' Kowalczyk]

Mon, 12 Feb 2001 11:39:12 -0700, Alastair Reid <reid at cs.utah.edu> pisze:

> > The ability to specify #include files in a portable way,
> 
> Can this not be done with one small extension instead of a much
> larger general purpose extension?

I prefer a not too large but generic feature - to one small extension
here, one small extension there, and debates how to express yet
another small detail again.

> The ffi spec already has a way to specify this: list it with each
> ffi decl. There's no need to invent anything new.

This is a C-specific feature added to the general FFI spec. My proposal
makes the FFI simpler by expressing all optional tuning parameters
(like unsafe and the calling convention, and e.g. the compiler if
a foreign language has binary-incompatible implementations that we
want to support) in a single unified syntactic framework.

> I'm looking for a compelling argument that the convenience of adding
> all these extra declarations outweighs the costs of a more complex
> design, introducing more keywords into the language, etc.

It does not introduce more keywords!

> Can't you just add the required functionality (global library
> declarations, global calling convention declarations, order-dependent
> overriding, etc.) to hsc2hs?

It's much simpler and more reliable to implement it in the compilers.

> Why not write a preprocessor that turns ffi/Java into ffi/C?

It's much simpler and more reliable to implement it in the compilers.

> Chances are that one of the existing calling conventions (i.e.,
> stack and register layouts) and the existing set of types is going
> to be a pretty good fit.

Correct programs must not rely on chances.

> If you find yourself using a Haskell implementation that runs
> on a JVM and want to optimize it (e.g., support some Java types
> more directly), you can tweak ffi/Java to generate native Java or
> marshall some types more intelligently or whatever.

Sorry, I don't understand.

>   Keep the ffi standard simple so that:
> 
>   1) An already hairy piece of code doesn't become unmaintainable.

Which piece of code do you have in mind? Existing libraries using
the FFI? My proposal is perfectly backwards-compatible.

>   2) Incompatabilities between different implementations can be kept to
>      a minimum.

My proposal reduces existing incompatibilities in a concrete way
(nhc98's noproto can be written such that it does not break ghc) and
keeps future incompatibilities to a minimum (header files needed by
ghc will not break nhc98 which does not use them).

>   And the way to achieve this is to put any proposed complexity in
>   tools rather than in the ffi.

Not everything can or should be put in tools.

> > Of course they are not keywords in any context except foreign
> > language declaration. That's why I wrote "pseudokeywords".
> 
> I hope you don't mean anything like Haskell 98's "as", "qualified"
> and "hiding" special identifiers?

It's like existing export, label, ccall, stdcall, unsafe, dynamic.
If you accept them, you must also accept this aspect of my proposal.

> Surely there's a better way?

Where?

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTÊPCZA
QRCZAK