- FFI - Haskell.org

RE: Revised FFI syntax + typing
by Simon Marlow 06 May '01

06 May '01

> > Why is Word a GHC extension? Someone remind me? > > Hmmm, I thought that the Word type itself is a GHC extension, the > hslibs docs for module Word only talk about the explictly sized > variants. OTOH the implementation exports Word, but for legacy > reasons, IIRC. If this is really the case, we should document this > somehow in the sources. I don't think I have any strong feelings either way. Word has a pleasing symmetry with Int, but on the other hand if it isn't useful then we should omit it. I agree in principle with Alastair's portability argument, but don't think it is worth applying for this particular case since we already have Int. Cheers, Simon

3 2

RE: FFI Definition
by Simon Peyton-Jones 02 May '01

02 May '01

| > language specific stuff inside the "..." string | > language independent stuff outside | | But static/dynamic probably means different things, depending | on the callconv. I think it's arguable that static/dynamic should be inside the ext_ent string. Indeed, one might use static/dynamic for ccall, and virtual/non-virtual/static for Java, etc. "Baking in" static/dynamic for all languages may be inappropriate. Nevertheless, you propose keeping 'mode' outside the ext_ent string. Why? (Apart from backward compat.) Also should 'label' be there? Doesn't make sense for Java, does it? Simon

1 0

RE: FFI Definition
by Simon Peyton-Jones 02 May '01

02 May '01

| * I'm not very happy with the fact that static/dynamic are | only viewed | as modifiers, like unsafe/safe. They almost completely change the | meaning of a foreign declaration, including the typing rules. In my | view, we have *5* different language constructs: `foreign import', | `foreign import dynamic', `foreign export', `foreign | export dynamic', | and `foreign label'. | * How will we differentiate between virtual vs. non-virtual | methods in | the cplusplus calling convention? What about class methods vs. | instance methods? Will these distinctions have influence on the | typing rules? If yes, coding this into the extent would be wrong. | | * The JVM has *4* different instructions for method invocation | (invokeinterface, invokespecial, invokestatic, and | invokevirtual), so | our static/dynamic distinction seems a bit inflexible here. And the | introduction of the "new" prefix looks like a hack, which doesn't | even handle all situations. These are good questions. I think it's inevitable that the form of type of the foreign thing is going to depend on per-language details. For C we have call call indirect label For Java we have 4 different invocations new For C++ we have call virt call non-virt new Etc. Each of these implies a particular form for the type. I think we have to bite the bullet and put this stuff in the language specific string, including our current static/dynamic thing. The compiler has to be able to parse this string in order to generate an appropriate call, so it's no big deal for this parse info to feed into the type checker too. This is moving in exactly the opposite of what Sven suggests, but I don't see any alternative. My criterion is language specific stuff inside the "..." string language independent stuff outside Simon

2 1

Revised FFI syntax + typing
by Sven Panne 02 May '01

02 May '01

OK, after SPJ's mail and a few beers I'm now convinced that typing the foreign construct is not as simple and orthogonal as I initially hoped. After a close look into GHC's internals, H/Direct and Hugs I propose the following in the hope that it's backwards compatible and not too confusing: ------------------------------------------------------------------------ Syntax for the 'foreign' language construct ------------------------------------------------------------------------ topdecl : 'foreign' fkind modifier* var '::' type -- even this could be merged into modifier somehow, but... :-P fkind : 'import' | 'export' | 'label' modifier : mode | callconv | safety | ext_ent -- allowed for import/export mode : 'static' -- default | 'dynamic' -- allowed for import/export callconv : 'ccall' -- default | 'wincall' | 'stdcall' -- deprecated, same as wincall | 'cplusplus' | 'jvm' | 'dotnet' -- allowed for import safety : 'safe' -- default | 'unsafe' -- allowed for static import/export and label ext_ent : string -- default: the string rep. of var | string string -- deprecated, first string ignored ------------------------------------------------------------------------ Types related to the FFI ------------------------------------------------------------------------ Note that data type renamings are completely "transparent", just like type synonyms. prim_type_i : ['IO'] prim_result_i | prim_arg_i '->' prim_type_i prim_arg_i : prim_arg | foreign_ty | unsafe_arr_ty -- GHC extension | unlifted_prim_ty -- GHC extension prim_result_i : prim_result | ['IO'] unlifted_prim_ty -- GHC extension prim_type : ['IO'] prim_result | prim_arg '->' prim_type prim_result : prim_arg | '()' prim_arg : int_ty | word_ty | float_ty | ptr_ty | 'Bool' | 'Char' | 'StablePtr' a int_ty : 'Int' | 'Int8' | 'Int16' | 'Int32' | 'Int64' word_ty : 'Word8' | 'Word16' | 'Word32' | 'Word64' | 'Word' -- GHC extension float_ty : 'Float' | 'Double' ptr_ty : 'Addr' -- deprecated | 'Ptr' prim_result_i | 'FunPtr' prim_type_i -- arguments of this type are kept alive automagically across FFI calls. foreign_ty : 'ForeignObj' -- deprecated | 'ForeignPtr' prim_result -- GHC extension, only in conjunction with 'unsafe' modifier unsafe_arr_ty : 'ByteArray' a | 'MutableByteArray' i s a -- GHC extension unlifted_prim_ty : <any unlifted primary type> ------------------------------------------------------------------------ Typing rules for the ccall/wincall/stdcall calling convention ------------------------------------------------------------------------ Note that safety and ext_ent can be ignored for typing purposes, and that prim_type{,_i}1 and prime_type{,_i}2 must be equal. foreign import static :: prim_type_i foreign import dynamic :: 'FunPtr' prim_type_i1 '->' prim_type_i2 foreign export static :: prim_type foreign export dynamic :: prim_type1 -> 'IO' ('FunPtr' prim_type2) foreign label :: ptr_ty Cheers, Sven

1 0

RE: ForeignObj and ForeignPtr
by Simon Marlow 01 May '01

01 May '01

> In the course of trying to find out GHC's status quo of typing foreign > declarations and scribbling together the forthcoming typing rules, I > stumbled over ForeignObj/ForeignPtr. There was a lively > discussion about > this some time ago IIRC, but I'm unsure about a few things: > > * ForeignObj has been deprecated for a long time, but we > should still > keep it in the FFI for a transition time and pass the associated > Addr when calling out, correct? Yes, at least another major release or two. > * Does it make sense to allow ForeignObj/ForeignPtr as a > prim_result? > I think it doesn't, because the non-Haskell side can't > know if and > when the finaliser has been run. That's right, ForeignPtrs exist inside the Haskell world only. When a ForeignPtr is passed outside, it is passed as a plain address, and an address cannot be converted back to a ForeignPtr for returning to Haskell. > * What did we conclude about the lifetime rules? Should > ForeignObj/ForeignPtr > arguments be handled specially by the FFI or is > {touch,with}Foreign{Obj,Ptr} > required? I'd opt for the latter, but the current FFI > docs seem to imply > a special handling. :-P I'd prefer to keep the "special" handling. Otherwise, we might as well disallow ForeignPtrs as arguments to foreign import, because you'd end up writing withForeignObj f $ \ p -> c_fun p all the time. Much simpler to make this automatic, and in some sense the "special" behaviour is really the expected behaviour (or rather, the alternative behaviour is simply not useful). > On the other hand, I can't see anything > special in the code generated by GHC. Hmmm... That's because it got lost after some changes to the pre-code-generation passes in GHC 5.00. It's on my list of things to fix. Cheers, Simon

1 0

ForeignObj and ForeignPtr
by Sven Panne 01 May '01

01 May '01

In the course of trying to find out GHC's status quo of typing foreign declarations and scribbling together the forthcoming typing rules, I stumbled over ForeignObj/ForeignPtr. There was a lively discussion about this some time ago IIRC, but I'm unsure about a few things: * ForeignObj has been deprecated for a long time, but we should still keep it in the FFI for a transition time and pass the associated Addr when calling out, correct? * Does it make sense to allow ForeignObj/ForeignPtr as a prim_result? I think it doesn't, because the non-Haskell side can't know if and when the finaliser has been run. * What did we conclude about the lifetime rules? Should ForeignObj/ForeignPtr arguments be handled specially by the FFI or is {touch,with}Foreign{Obj,Ptr} required? I'd opt for the latter, but the current FFI docs seem to imply a special handling. :-P On the other hand, I can't see anything special in the code generated by GHC. Hmmm... Cheers, Sven

1 0

RE: FFI typing issues [was: Typing f.e.d.]
by Simon Marlow 30 Apr '01

30 Apr '01

> The first one is the typing of `foreign import dynamic', which is > documented as > > Addr -> (prim_args -> IO prim_result) (actually the Addr can currently be 'Ptr a' or 'FunPtr a' too). > GHC currently implements more or less `Addr -> prim_type', > but that's not > the point here. I propose changing this to > > FunPtr prim_type1 -> prim_type2 -- where prim_type1 == prim_type2 > > again deprecating and keeping the old typing. Apart from the purely > technical `IO' (hmmmm, is this *really* necessary?), it makes things > almost symmetrical to f.e.d. Looks reasonable to me. > Another point is the typing of `foreign label', which is > currently simply > > Addr > > I propose to change this to *two* possible typings: > > Ptr a > FunPtr a I think it's currently Ptr a, FunPtr a, or Addr (see TysWiredIn.isFFILabelTy). > Should we make newtype completely transparent? I think so, yes. Cheers, Simon

1 0

Typing f.e.d.
by Sven Panne 30 Apr '01

30 Apr '01

I have a small change request regarding foreign export dynamic. Currently the FFI doc says: topdecl : ... .. | 'foreign' 'export' [callconv] 'dynamic' varid :: prim_type -> IO Addr GHC additionally allows: prim_type -> IO Ptr As usual the FFI "looks through" newtypes. But now that we have FunPtr, the following typing makes much more sense: 'foreign' 'export' [callconv] 'dynamic' varid :: prim_type -> IO (FunPtr prim_type) where both prim_types have to be the *same*. We should probably allow the old Addr-typing as well for some time to facilitate the transition, but not the Ptr-typing (bleeding edge people will know what to do :-). The corresponding changes to GHC look easy, so I'd like to commit this if there are no objections. Furthermore, the FFI docs still talk about Addr only, not Ptr/FunPtr. Now that Addr is deprecated, this should be changed, too. Cheers, Sven

5 7

RE: FFI progress
by Simon Marlow 30 Apr '01

30 Apr '01

> In this context, I actually find it the identifier `stdcall' > strange. Why is it standard? I'd argue that ccall is the > standard (in fact, it so far was the default, wasn't it?) It's known as 'stdcall' on Windows. In fact, VC++ has __stdcall keyword. All the Win32 API functions are declared __stdcall. So, I guess that's why we called it stdcall in Haskell. Cheers, Simon

2 1

RE: FFI progress
by Simon Peyton-Jones 17 Apr '01

17 Apr '01

Manuel | The FFI discussion seems to be completely stalled. Would | you, as our Tsar, like to summarise the state of play, and | re-invigorate it? There was a bit of discussion, which led, I think to a simplification of the library stuff. But we don't have a summary (even informal) of the current state of play, and that's beginning to be a problem here because we're about to implement the .NET FFI for GHC. Might I suggest http://research.microsoft.com/~simonpj/ffi.html as the basis for a state-of-play-summary. You can grab the source and modify it as you see fit. There's one particular issue we havn't discussed. For Java and .NET we want to call static methods, dynamic methods, and constructors. We already have foreign import static foreign import dynamic but 'new' is different again. The obvious place for it is in the language-specific string foreign import static "new foo(int x)" foo :: Int -> IO Foo It seems a bit odd to have static/dynamic *outside* but "new" inside the language-specific string. I suppose the justification is that 'new' is really a static method with a funny way to call it. Whereas the 'self' parameter on a dynamic call is treated specially. So that's ok, but we should agree that's what we want. Simon

3 2