Modification to foreign import/export

[Marcin 'Qrczak' Kowalczyk]

Wed, 21 Feb 2001 11:41:07 -0700, Alastair Reid <reid at cs.utah.edu> pisze:

> The point of me mail was that instead of using half the features
> of cpp (Marcin gave an example which used #ifdef) and extending the
> ffi spec to do the other half, he could use all the features of cpp
> (#ifdef and #define) and avoid the ffi extension.

Applying cpp to a Haskell source is problematic, because it doesn't
have the same lexical syntax as C. Apostrophes in identifiers
and string gaps cause most trouble. And it does not solve all FFI
problems for which some preprocessing is needed, e.g. expanding numeric
constants defined in C headers (you can't include a C header full of
function prototypes into a Haskell source, although it could probably
be worked around by wrapping in comments).

My example using #ifdef was meant to use hsc2hs instead of cpp.
I don't use cpp for Haskell.

I understand that making official FFI depending on an extra tool
(which may be considered an ad-hoc solution) is problematic in itself,
so I don't propose making hsc2hs a part of the standard now. But I
found it practical for FFI - definitely more appropriate than cpp.

> If we want to rule cpp as out of bounds (a very worthwhile but
> difficult goal), then we need to think about how to avoid conditional
> compilation too.

Unfortunately it is sometimes needed. We can try to isolate it etc.,
but it will be needed because we don't live in a perfectly portable
world.

I am making a wrapper for the Python interpreter in Haskell programs,
or Haskell<->Python binding if you like. I already used the following
features of hsc2hs:

* #include <Python.h>
* C functions written inline in Haskell source, for wrapping C macros.
  Warnoing: their prototypes should be #included into modules which
  import modules which define them, because ghc inlines calls to C
  functions across modules.
* Conditional compilation for broken Haskell compilers, e.g.
  non-working foreign label and broken newtype handling in foreign
  export.
* Definition of a C struct and accessing its fields and sizeof inline
  in Haskell source.
* Conditional compilation for non-standard ghc modules:
  Exception.justDynExceptions was renamed to Exception.dynExceptions
  in ghc-4.09.
* Conditional compilation for Python interpreter versions: some
  functions were added in Python 2.0, some were renamed (old names
  are available as macros, but they would need preprocessor support
  anyway).

I will also use conditional compilation for being able to use either
native ghc FFI modules or versions provided by QForeign. Using versions
from QForeign has two advantages for me here: works with ghc-4.08* and
allows to play with charset conversions and Unicode.


The last point leads to the following problem. I would like to be able
to override modules found in -package lang with my modules, i.e. use
modules with the same names, and have minimal control which are used
(relying on ordering of -package options suffices).

The problem is that these modules use features from original modules
that I want to shadow. It seems to work with nhc98, but ghc is confused
when several modules of the same name are indirectly imported to
the same module - in this case a module reexports a function from
a module with the same name. I also expect problems with internal
__init_Module functions.

Note that I don't directly import both modules at the same time.
I tried to have my modules under different names importing original
modules, and then in a separate directory compiling my modules with
shadowing names which just reexport previously defined modules with
different names. But it does not work if original functions are really
defined in modules of the same name (it seems to work when functions
come from yet other ghc private modules).

We could just say that using multiple modules of the same name is
evil and will never be supported. Nevertheless in my case it would
be very useful. My modules have the same functionality as original
modules and reexport their contents in most cases, but sometimes they
have a slightly different implementation. Currently my modules have
different names, so code using them must explicitly call for them.
It's not a matter of switching -package options, but either conditional
compilation or playing with directories containing reexporting
modules having non-standard names *in a package which uses my modules*
(requiring to play tricks would be OK for my modules which play tricks
with shadowing, but not everywhere they are used).

If ghc internally fully qualified functions with packages, not only
with modules, then it should work.

Do you too think that ghc should enable a package to reuse module names
from different packages, even if it indirectly uses these packages?

Perhaps it should be integrated with proposed Malcolm's scheme of
structured module hierarchy. It's not obvious how ghc's packages fit
into this idea.

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