HDirect A Binary Foreign Language Interface for Haskell Sigb jorn Finne Daan Leijen Erik Meijer Simon Peyton Jones April HDirect provides the means to leverage that primitive fa Abstract cility into the full glory of IDL HDirect is a foreignlanguage interface for the purely func Because they cater for a variety of languages foreign tional language Haskel l Rather than rely on hostlanguage language interfaces tend to b ecome rich complex incom type signatures HDirect compiles Interface Denition Lan plete and describ ed only by example The main contribu guage IDL to Haskel l stub code that marshals data across tion of this pap er is to provide part of a formal descrip the interface This approach al lows Haskel l to call both C tion of the interface This precision encompases not only and COM and al lows a Haskel l component to be wrapped the programmerseye view of the interface but also its im in a C or COM interface IDL is a complex language and plementation The bulk of the pap er is taken up with this language mappings for IDL are usual ly described informal ly description In contrast we provide a relatively formal and precise de nition of the mapping between Haskel l and IDL Background This paper has been submitted to the International Confer ence on Functional Programming ICFP The basic way in which almost any foreignlanguage inter face works is this The signature of each foreignlanguage pro cedure is expressed in some formal notation From this Introduction signature stub co de is generated that marshals the param eters across the b order b etween the two languages calls A foreignlanguage interface provides a way for programs the pro cedure using the foreign languages calling conven written in one language to call or b e called by programs tion and then unmarshals the results back across the b or written in another Programming languages that do not sup der Dealing with the dierent calling conventions of the two ply a foreignlanguage interface die a slow lingering death languages is usually the easy bit The complications come go o d languages die more slowly than bad ones but they in the parameter marshalling which transforms data values all die in the end built by one language into a form that is comprehensible to In this pap er we describ e a new foreignlanguage for the the other functional programming language Haskell In contrast to A ma jor design decision is the choice of notation in which earlier foreignlanguage interfaces for Haskell such as Green to describ e the signatures of the pro cedures that are to b e Card we describ e a design based on a standard Interface called across the interface There are three main p ossibili Denition Language IDL We discuss the reasons for this ties decision in Section Our interface provides direct access to libraries written in Use the host language Haskel l in our case That C or any other language using Cs calling convention is write a Haskell type signature for the foreign func and makes it p ossible to write Haskell pro cedures that can tion and generate the stub co de from it Green Card b e called from C The same to ol also makes it allows us uses this approach as do es JDirect Microsofts to call COM comp onents directly from Haskell or to foreignlanguage interface for Java seal up Haskell programs as a COM comp onent COM is Microsofts comp onent ob ject mo del it oers a language Use the foreign language say C In this case the stub indep endent interface standard b etween software comp o co de must b e generated from the C prototype for the nents The interfaces of these comp onents are written in pro cedure SWIG uses this approach IDL Use a separate Interface Denition Language IDL HDirect generates Haskell stub co de from IDL interface designed sp ecically for the purp ose descriptions It is carefully designed to b e indep endent of the particular Haskell implementation To maintain this in We discuss the rst two p ossibilities in Section and the dep endence HDirect requires the implementation to sup third in Section p ort a primitive foreignlanguage interface mechanism ex pressed using a nonstandard Haskell foreign declaration Using the host or foreign language The signature of a foreign pro cedure may say to o little ab out allo cation resp onsibilities For example if the At rst sight the rst two options lo ok much more conve caller passes a data structure to the callee such as a nient than the third b ecause the caller is written in one string can the latter assume that the structure will language and the callee in the other so the interface is con still b e available after the call Do es the caller or callee veniently expressed for at least one of them Here for exam allo cate space to hold the results ple is how JDirect allows Java to make foreignlanguage In an earlier pap er we describ ed Green Card whose basic calls approach was to use Haskell as the language in which to give the type signatures for foreign pro cedures To deal with class ShowMsgBox the issues describ ed ab ove we provided ways of augmenting public static void mainString args the Haskell type signature to allow the programmer to cus tomise the stub co de that would b e generated However MessageBoxHelloJava Messagebox Green Card grew larger and larger and we realised that what b egan as a mo dest design was turning into a fullscale language dllimportUSER private static native int MessageBox int hwndOwner String text Using an IDL String title int fuStyle Of course we are not the rst to encounter these diculties The standard solution is to use a separate Interface Deni tion Language IDL to describ e the signatures of pro ce The dllimport directive tells the compiler that the dures that are to b e called across the b order IDLs are rich Java MessageBox metho d will link to the native Windows and complicated for precisely the reasons describ ed ab ove USERDLL The parameter marshaling for example of the but they are at least somewhat standardised and come with strings is generated based on the Java type signature for useful to ols We fo cus on the IDL used to describ e COM MessageBox interfaces which is closely based on DCE IDL An The fatal aw is that it is invariably impossible in general other p opular IDL dialect is the one dened by OMG as part to generate adequate stub code based solely on the type sig of the CORBA sp ecication and we intend to provide nature of a procedure in one language or the other There supp ort for this using the translation from OMG to DCE are three kinds of diculties IDL dened by 1 Like COM but unlike CORBA we take the view that the First some practicallyimp ortant languages notably IDL for a foreign pro cedure denes a languageindependent C have a type system that is to o weak to express the binary interface to the foreign procedure a sort of lin necessary distinctions For example gua franca The interface thus dened is supp osed to b e The stub co de generator must know the mo de of complete it covers calling convention data format and al each parameter in in out or out b ecause lo cation rules It may b e necessary to generate stub co de each mo de demands dierent marshaling co de on b oth sides of the b order to marshal parameters into the IDLmandated format and then on into the format de Some p ointers have a signicant NULL value while manded by the foreign pro cedure But these two chunks others do not Some p ointers p oint to values that of marshaling co de can b e generated separately each by a can and sometimes should b e copied across the to ol sp ecialised to its host language By design however b order while others refer to mutable lo cations IDLs binary conventions are more or less identical to Cs whose contents must not b e copied so marshaling on the C side is hardly ever necessary There may b e imp ortant interrelationships b e Here for example is the IDL desribing the interface to a tween the parameters For example one param function foo eter might p oint to an array of values while an other gives the number of elements in the array int foo out long l The marshaling co de needs to know ab out such string in char s dep endencies in out double d On the other hand it may not even b e enough to give the signature in a language with an expressive type The parts in square brackets are called attributes In this case system such as Haskell The trouble is that the type they describ e the mo de of each parameter but there are a signature still says to o little ab out the foreign pro ce rich set of further attributes that give further and often dures type signature For example is the result of a essential information ab out the type of the parameters For Haskell pro cedure returned as the result of the foreign example the string attribute tells that the parameter s pro cedure or via an out parameter of that pro cedure p oints to a nullterminated array of characters rather than In the case of JDirect when a record is passed as an p ointing to a single character argument Javas type signature is not enough to sp ec 1 CORBA do es not dene a binary interface Rather each ORB ify the layout of the record b ecause Java do es not sp ec vendor provides a language binding for a number of supp orted lan ify the layout of the elds of an ob ject and the garbage guages This language binding essentially provides the marshaling required to an ORBsp ecic common calling convention If you want collector can move the ob ject around in memory to use a language that the ORB vendor do es not supp ort you are out of luck do a marshalPoint p primMove