FFI Report, CVS Id 1.5

[malcolm-ffi at cs.york.ac.uk]

> > >     foreign import "static foo" foo :: t
> > >     foreign import "static"     foo :: t
> > >     foreign import ""           foo :: t
> > > 
> > >   Is the last one nice?
> >
> > (I still think that the "static" keyword is not necessary.)
>
> How would you import a function named "static" then?

I don't know whether we are still worrying about backwards
compatibility, but
          foreign import "static"     foo :: t
at the moment declares a function called "static" in the foreign
language and "foo" in Haskell.

Is the idea that, in the new scheme, this declares a function called
"foo" in both Haskell and the foreign language, but with an attribute
"static" in the foreign domain?

And so to declare the former kind of thing, we'd need
          foreign import "static static"     foo :: t
?

I don't much mind either way, since it is a trivial and unlikely
situation, but could someone clarify please?

> > > I have added a restriction: exported variables must be
> > > defined by a function or pattern binding in the *same*
> > > module.

I had understood that this was always the case anyway.
      foreign export f :: t
is the sole type declaration for f.  Just as it is an error to have
more than one type decl for f, so you can't write an additional
      f :: t
in the same file.  And just as you cannot write a type decl for
an entity imported from a different module, you can't write a
foreign export for an imported entity either.

> Again, I'm with Marcin. This restriction looks very artificial and ugly.

On the contrary, I think it is a very natural interpretation.  That is
also how it is implemented in nhc98, which is something I need to
keep my eye on of course - I am not a type system hacker, and I'm
afraid I wouldn't know how to implement it any other way currently.

Regards,
    Malcolm