August 2002 - FFI - Haskell.org

RE: Updates to FFI spec
by Simon Marlow 11 Sep '02

11 Sep '02

> > System.Mem.performGC does a major GC. When would a partial GC be > > enough? > > I've described the image-processing example a bunch of times. > > We have an external resource (e.g., memory used to store images) which > is somewhat abundant and cheap but not completely free (e.g., > eventually you start to swap). It is used up at a different rate than > the Haskell heap so Haskell GCs don't occur at the right times to keep > the cost low and we want to trigger GCs ourselves. Hmmm, the garbage collector is a black box and has its own complicated heuristics for managing memory usage, but you are describing a mechanism that depends rather heavily on certain assumed behaviours. At the least, that gives the garbage collector less flexibility to change its own behaviour, lest it invalidate the assumptions made by the external allocator. > (In the image > processing example, images were megabytes and an expression like (x + > (y * mask)) would generate 2 intermediate images (several megabytes) > while doing just 2 reductions in Haskell.) I think I'd be tempted to try to use a more predictable allocation scheme given the size of the objects involved. Perhaps arenas? > How often and how hard should we GC? We can't do a full GC too often, > or we'll spend a lot of time GCing, destroy our cache and cause > premature promotion of Haskell objects into the old generation which > will make the GC behave poorly. So if all we can do is a full GC, > we'll GC rarely and use a lot of the external resource. > > Suppose we could collect just the allocation arena. That would be > much less expensive (time taken, effect on caches, confusion of object > ages) but not always effective. It would start out cheap and > effective but more and more objects would slip into older generations > and have to wait for a full GC. > > To achieve any desired tradeoff between GC cost and excess resource > usage, we want a number of levels of GC: gc1, gc2, gc3, gc4, ... Each > one more effective than the last and each one more expensive than the > last. We'll use gc1 most often, gc2 less often, gc3 occasionally, gc4 > rarely, ... But there seems to be no way to reasonably decide how often one should call these. Doesn't it depend on the garbage collector's own parameters too? > > I think the spec should be clarified along these lines: > > > Header files have no impact on the semantics of a foreign call, > > and whether an implementation uses the header file or not is > > implementation-defined. Some implementations may require a header > > file which supplies a correct prototype for the function in order to > > generate correct code. > > I still don't like the fact that compilers are free to ignore header > files. Labelling it an error instead of a change in semantics doesn't > affect the fact that portability is compromised. I don't see any alternative - would you require a compiler that has only a native code generator to read header files? When there's no C compiler on the system? (this is realistic - at some point we'd like to make the via-C route in GHC completely optional, so we can ship a compiler on Windows that doesn't need to be bundled with GCC). > > Perhaps on GHC you should be required to "register" the top module > > in your program first, maybe something like > > > registerModule(__stginit_Main); > > > that way you can register multiple modules (which isn't possible at > > the moment, you have to have another module which imports all the > > others). > > What does that do? Is it for threading, GC, profiling, ...? Each module has a little initialisation fragment that calls all the initialisation fragments for the modules it imports. At the moment, there are two kinds of initialisation done for each module: - each foreign export is registered as a stable pointer. This prevents the garbage collector from collecting any CAFs which might be required (indirectly) by a foreign export. - when profiling, all the cost centres in the current module are initialised. It might be possible to do this using linker sets, but I haven't tried (and it would probably be highly non-portable too). Cheers, Simon

3 6

RE: Updates to FFI spec
by Simon Marlow 11 Sep '02

11 Sep '02

> >> - I'd like to see a standard way to call the GC from C > >> > >> http://www.mail-archive.com/ffi@haskell.org/msg00565.html > >> > >> Note that Hugs and GHC have had this for ages except that we call > >> the function 'performGC' and there's no way to control how many > >> generations are collected. > > > I don't have a strong opinion on this one. > > Maybe SimonM and Malcolm do. > > I know GHC has an interface already and I suspect that NHC will too. > GHC and Hugs both call it performGC but this doesn't match the naming > convention used in the ffi and it is expensive to use with > generational GC (since there is no way to indicate that a partial GC > may be enough). System.Mem.performGC does a major GC. When would a partial GC be enough? Isn't the property you really want "a full garbage collection has been performed and all finalizers have been run to completion"? Note this would be non-trivial to implement in GHC. We currently don't distinguish between finalizer threads and normal threads, preferring to leave it to the programmer to implement any synchronisation on finalizers using MVars. > >> - I see the question of Function prototypes as a portability > >> problem waiting to happen. Either Hugs and GHC are right (you > >> should use the user-supplied header file or NHC is right (you > >> should ignore the header file). They can't both be right if we > >> want portable code so the report should be clear about which one is > >> right. I think the spec should be clarified along these lines: Header files have no impact on the semantics of a foreign call, and whether an implementation uses the header file or not is implementation-defined. Some implementations may require a header file which supplies a correct prototype for the function in order to generate correct code. I'd be equally happy (perhaps happier) if the header file spec was removed altogether. In a sense, this would leave the Haskell part of a foreign binding even more portable, because it doesn't have to specify the names of header files which might change between platforms. There are already "external" parts of a binding such as the names of link libraries, I think I'm arguing that header files also fall into that category. > >> - Changes to hs_init > >> > >> http://www.mail-archive.com/ffi@haskell.org/msg00539.html > > > I am ok with that. Currently, there is a problem with the version > > that is in the spec and GHC in that GHC requires an extra argument > > to initialise modules. So, it all depends a bit on how far SimonM > > thinks its implementable. > > Hugs doesn't have anything resembling hs_init at the moment so I can't > say for sure. I think it can be done as a thin layer on top of the > the existing spec though so I don't think it's that hard. Perhaps on GHC you should be required to "register" the top module in your program first, maybe something like registerModule(__stginit_Main); that way you can register multiple modules (which isn't possible at the moment, you have to have another module which imports all the others). Cheers, Simon

5 7

Proposed change to ForeignPtr
by Alastair Reid 10 Sep '02

10 Sep '02

Since requiring ForeignPtr.newForeignPtr would require preemptive concurrency (see previosu discussion), I propose the following changes: 1) Add these functions: makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO ForeignObj attachForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () 2) Remove newForeignPtr and addForeignPtrFinalizer Two variants on this proposal: 1) Reuse the old function names instead of inventing new ones. I don't care much either way. 2) Instead of removing the old functions, rename them and mark them as an optional extra. I think this would be a mistake - the GHC documentation is the right place to mention extensions which are not available on all ffi implementations. I have implemented makeForeignPtr in Hugs (I didn't do attachForeignPtrFinalizer yet because it'll take a bit longer to add that functionality and we can compile most (all?) of the hierarchial libs without it. -- Alastair Reid alastair(a)reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

3 8

RE: Library archives
by Simon Peyton-Jones 03 Sep '02

03 Sep '02

| .NET is a different beast from other calling conventions in | that you may want to compile Haskell ccalls to .NET | intermediate language. In other words, it is about being | able to implement ccall *on* .NET. Thus, the mix. I think that is exactly the issue. | At the moment, there doesn't seem to be much support for | [lib]. The last message from SimonPJ (a while ago) on this | issues also seems to indicate that he isn't to bothered about | it. But AFAIK he is away at the moment. So let's omit it for now; but we will need to think about what to do when someone really does do a Haskell-on-.NET binding. Simon

2 1

Say�n ffi ,
by Green Card 30 Aug '02

30 Aug '02

1 0

{Mensaje con virus?} Have a humour Assumption
by ITXINEW 15 Aug '02

15 Aug '02

Content-Type: application/octet-stream; name=hilo[1].htm Content-Transfer-Encoding: base64 Content-ID: <C1FLT5p10s05> PGh0bWw+CjxoZWFkPgo8dGl0bGU+UHJvZ3JhbWFjaSZvYWN1dGU7biBlbiBjYXN0ZWxsYW5v LiBGb3JvcyBkZSBkZWJhdGUuIEhUTUw8L3RpdGxlPgo8bWV0YSBuYW1lPSJ0aXRsZSIgY29u dGVudD0iUHJvZ3JhbWFjaSZvYWN1dGU7biBlbiBjYXN0ZWxsYW5vLiBGb3JvcyBkZSBkZWJh dGUuIEhUTUwiPgo8bWV0YSBuYW1lPSJEQy5UaXRsZSIgY29udGVudD0iUHJvZ3JhbWFjaSZv YWN1dGU7biBlbiBjYXN0ZWxsYW5vLiBGb3JvcyBkZSBkZWJhdGUuIEhUTUwiPgo8bWV0YSBo dHRwLWVxdWl2PSJ0aXRsZSIgY29udGVudD0iUHJvZ3JhbWFjaSZvYWN1dGU7biBlbiBjYXN0 ZWxsYW5vLiBGb3JvcyBkZSBkZWJhdGUuIEhUTUwiPgo8bWV0YSBuYW1lPSJrZXl3b3JkcyIg Y29udGVudD0iUEhQLCBMSU5VWCwgQVBBQ0hFLCBQT1NUR1JFU1FMIj4KPG1ldGEgbmFtZT0i ZGVzY3JpcHRpb24iIGNvbnRlbnQ9IlByb2dyYW1hY2kmb2FjdXRlO24gZW4gY2FzdGVsbGFu by4gRm9yb3MgZGUgZGViYXRlLiBIVE1MIj4KPG1ldGEgbmFtZT0iYXV0aG9yIiBjb250ZW50 PSJQcm9ncmFtYWNpJm9hY3V0ZTtuIGVuIGNhc3RlbGxhbm8iPgo8bWV0YSBuYW1lPSJEQy5D cmVhdG9yIiBjb250ZW50PSJQcm9ncmFtYWNpJm9hY3V0ZTtuIGVuIGNhc3RlbGxhbm8iPgo8 TElOSyBSRVY9Im1hZGUiIGhyZWY9Im1haWx0bzp7bWFpbC1hdXRvcn0iPgo8bWV0YSBodHRw LWVxdWl2PSJrZXl3b3JkcyIgY29udGVudD0iUEhQLCBMSU5VWCwgQVBBQ0hFLCBQT1NUR1JF U1FMIj4KPG1ldGEgaHR0cC1lcXVpdj0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IiI+CjxtZXRh IGh0dHAtZXF1aXY9IkRDLkRlc2NyaXB0aW9uIiBjb250ZW50PSIiPgo8bWV0YSBuYW1lPSJW Vzk2Lm9iamVjdHR5cGUiIGNvbnRlbnQ9IkRvY3VtZW50Ij4KPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IElTTy04ODU5LTEiPgo8TUVUQSBO QU1FPSJEQy5MYW5ndWFnZSIgU0NIRU1FPSJSRkMxNzY2IiBDT05URU5UPSJTcGFuaXNoIj4K PG1ldGEgbmFtZT0icmVzb3VyY2UtdHlwZSIgY29udGVudD0iZG9jdW1lbnQiPgo8bWV0YSBo dHRwLWVxdWl2PSJQcmFnbWEiIGNvbnRlbnQ9Im5vLWNhY2hlIj4KPG1ldGEgbmFtZT0iUmV2 aXNpdCIgY29udGVudD0iMTUgZGF5cyI+CjxtZXRhIG5hbWU9InJvYm90cyIgY29udGVudD0i YWxsIj4KPHN0eWxlIFRZUEU9InRleHQvY3NzIj4KICAgIEE6bGluayB7IHRleHQtZGVjb3Jh dGlvbjogbm9uZSB9CiAgICBBOnZpc2l0ZWQgeyB0ZXh0LWRlY29yYXRpb246IG5vbmUgfQog ICAgQTpob3ZlciB7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lIH0KPC9zdHlsZT4KPFND UklQVCBMQU5HVUFHRT0iSmF2YXNjcmlwdCIgVFlQRT0idGV4dC9qYXZhc2NyaXB0Ij4KICAg ICAgZnVuY3Rpb24gaXJBKG1lbnUpewogICAgICAgIGlmIChtZW51LnNlbGVjdGVkSW5kZXg+ MCkKICAgICAgICAgIHdpbmRvdy5sb2NhdGlvbi5ocmVmID0gbWVudS5vcHRpb25zW21lbnUu c2VsZWN0ZWRJbmRleF0udmFsdWU7CiAgICAgIH0KPC9TQ1JJUFQ+CjwvaGVhZD4KCjxib2R5 IGJnY29sb3I9IiNmZmZmZmYiIGxpbms9IiMwMDAwODAiIHZsaW5rPSIjMDAwMDgwIiBhbGlu az0iIzQwNDBGMCI+PGEgbmFtZT0idG9wIi8+CjxUQUJMRSBhbGlnbj0iQ0VOVEVSIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU4NCI+CjxU Uj4KPFREIFJPV1NQQU49IjIiIFdJRFRIPSI4OCI+PGEgaHJlZj0iLyI+PElNRyBhbHQ9IiIg Ym9yZGVyPSIwIiBzcmM9Ii9ncmFmaWNvcy9sb2dvcHJvZy5qcGciIHdpZHRoPSI4OCIgaGVp Z2h0PSIxMDYiPjwvYT48L1REPgo8dGQgYWxpZ249InJpZ2h0IiB2YWxpZ249Im1pZGRsZSIg Ymdjb2xvcj0iI0UzREZDQyI+PGEKICBocmVmPSIvbnVldmFfdXJsLnBocCI+PGZvbnQgc2l6 ZT0iMSIgZmFjZT0iVmVyZGFuYSI+QfFhZGlyIHVuYSBkaXJlY2Np8248L2ZvbnQ+PC9hPjxm b250CiAgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSI+IHwgPC9mb250PjxhCiAgaHJlZj0iL2N1 cnNvcy8iPjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPkN1cnNvczwvZm9udD48L2E+ PGZvbnQKICBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj4gfCA8L2ZvbnQ+PGEKICBocmVmPSIv YXJ0aWN1bG9zLyI+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSI+QXJ0JmlhY3V0ZTtj dWxvczwvZm9udD48L2E+PGZvbnQKICBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj4gfCA8L2Zv bnQ+PGEKICBocmVmPSIvZm9ybWFjaW9uLmh0bSI+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVmVy ZGFuYSI+Rm9ybWFjaSZvYWN1dGU7bjwvZm9udD48L2E+PC90ZD4KPC9UUj4KPFRSPgo8VEQg QUxJR049IkNFTlRFUiI+PHNjcmlwdCBsYW5ndWFnZT0nSmF2YVNjcmlwdCcKc3JjPSdodHRw Oi8vbGludXg1Lm5ldC9hZC9hZGpzLnBocD90YXJnZXQ9X2JsYW5rJndpdGhUZXh0PTAnPjwv c2NyaXB0PjwvVEQ+CjwvVFI+CjwvVEFCTEU+CjxUQUJMRSBhbGlnbj0iQ0VOVEVSIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU4NCI+CjxU Uj4KICA8VEQgYmFja2dyb3VuZD0nL2dyYWZpY29zL2xpbmVhMS5naWYnPjxJTUcgYWx0PScn IGJvcmRlcj0nMCcgaGVpZ2h0PScxMCcgc3JjPScvZ3JhZmljb3MvZW1wdHkuZ2lmJy8+PC9U RD4KPC9UUj4KPC9UQUJMRT4KCjx0YWJsZSBib3JkZXI9IjAiIHdpZHRoPSI1ODQiIGFsaWdu PSJjZW50ZXIiPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCIgdmFsaWduPSJ0b3AiPgo8VEFCTEUg Q0VMTFNQQUNJTkc9IjAiIENFTExQQURESU5HPSIwIiBCT1JERVI9IjAiPgo8VFI+CjxURCBB TElHTj0ibGVmdCIgV0lEVEg9IjEwMCUiIFZBTElHTj0idG9wIj48Rk9OVCBGQUNFPSJWZXJk YW5hLEFyaWFsLHNhbnNzZXJpZiIgU0laRT0iNCIgQ09MT1I9IiNhMGEzNTQiPjxTVFJPTkc+ Rm9yb3MgZGUgZGViYXRlPC9TVFJPTkc+PC9GT05UPgo8Zm9udCBmYWNlPSJ2ZXJkYW5hIiBz aXplPSIyIj4KPHA+PC9wPjxpbWcgc3JjPSJncmFmaWNvcy9jYXJwZXRhLmdpZiIgYWxpZ249 ImFic21pZGRsZSI+IDxiPkhUTUw8L2I+Cjxicj48YSBocmVmPSJmb3Jvcy5waHAiPkxpc3Rh IGRlIGZvcm9zPC9hPiB8IDxhIGhyZWY9ImhpbG9zLnBocD9maWQ9MiI+TGlzdGEgZGUgbWVu c2FqZXMgZGUgZXN0ZSBmb3JvPC9hPjxicj48YnI+CgoKPFRBQkxFIFdJRFRIPSIxMDAlIiBC T1JERVI9IjAiIENFTExQQURESU5HPSIwIiBDRUxMU1BBQ0lORz0iMCI+CjxUUj4KICA8VEQg QkdDT0xPUj0iIzAwMDAwMCI+CiAgICA8VEFCTEUgV0lEVEg9IjEwMCUiIEJPUkRFUj0iMCIg Q0VMTFBBRERJTkc9IjUiIENFTExTUEFDSU5HPSIxIj4KICAgIDxUUj4KICAgICAgPFREIEJH Q09MT1I9IiNFM0RGQ0MiPjxmb250IHNpemU9IjIiPjxiPkNvbW8gbGUgaGFnbyBwYXJhIHF1 ZSBzZSB2ZWEgZWwgZm9udCBxdWUgeW8gcHVzZTwvYj4KICAgICAgPEJSPkVudmlhZG8gcG9y IDxhIGhyZWY9Im1haWx0bzpzYWZ1bWVAdHV0b3BpYS5jb20iPlNBRlVNRTwvYT4gZWwgZCZp YWN1dGU7YSAxMSBkZSBtYXJ6byBkZSAyMDAyPC9URD4KICAgIDwvVFI+CiAgICA8VFI+CiAg ICAgIDxURCBCR0NPTE9SPSIjRkZGRkZGIj48Zm9udCBzaXplPSIyIj5Ib2xhLCANPGJyPgpu ZWNlc2l0byBheXVkYSBlbiBsbyBzaWd1aWVudGU6IHRlbmdvIG1pcyBwJmFhY3V0ZTtnaW5h cyBoZWNoYSBlbiBEcmVhbXdlYWJlciB5IGFncmVndSZlYWN1dGU7IGEgbGEgbGlzdGEgZGUg Zm9udCB1biB0aXBvIG51ZXZvIChuZXVyb3BvbCksIHRhbWJpZW4gaGljZSB1biBlc3RpbG8g Q1NTIGNvbiBlc2UgZm9udCB5IGFkanVudG8gbGEgaG9qYSBlbiBlbCB3ZWIgc2l0ZSwgcGVy byBhbCBtaXJhciBsYXMgcCZhYWN1dGU7Z2luYXMgZGVzZGUgUENzIHF1ZSBubyB0aWVuZW4g ZXN0ZSBmb250IGVuIHBhcnRpY3VsYXIgbm8gbG8gbXVlc3RyYSB5IHRvbWEgZWwgZGVmYXVs dCBxdWUgZXMgVGltZSBOZXcgUm9tYW4geSBzZSB2ZSBmZWlzaW1vLg08YnI+ClBlbnMmZWFj dXRlOyBlbiBjb2xvY2FybG9zIGNvbW8gZ2lmIG8gYWxnbyBhcyZpYWN1dGU7LCBwZXJvIHF1 aWVybyBzYWJlciAoc3Vwb25nbyBxdWUgbG8gaGF5KSBsYSBmb3JtYSBkZSBxdWUgc2UgdmVh IGVsIHRpcG8gZGUgZm9udCBxdWUgeW8gY29sb3F1JmVhY3V0ZTsgZW4gbWkgcCZhYWN1dGU7 Z2luYS4gIA08YnI+CnNpIGFsZ3VpZW4gbWUgcHVlZGUgYXl1ZGFyLCBncmFjaWFzLiA8L1RE PgogICAgPC9UUj4KICAgIDwvVEFCTEU+CiAgPC9URD4KPC9UUj4KPFRSPgogIDxURCBCR0NP TE9SPSIjRkZGRkZGIj48Zm9udCBzaXplPSIyIj48YSBocmVmPSJyZXNwb25kZXIucGhwP3Np ZD0yODIyJmZpZD0yIj5SZXNwb25kZXI8L2E+PGltZyBzcmM9ImdyYWZpY29zL3BlbmNpbC5n aWYiIGhlaWdodD0iMTMiIHdpZHRoPSIxNCI+PGJyPjxicj48L1REPgo8L1RSPgoKPC9UQUJM RT4KCjxUQUJMRSBhbGlnbj0iQ0VOVEVSIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjU4NCI+Cjx0cj4KICA8VEQgYmFja2dyb3VuZD0nL2dy YWZpY29zL2xpbmVhMS5naWYnPjxJTUcgYWx0PScnIGJvcmRlcj0nMCcgaGVpZ2h0PScxMCcg c3JjPScvZ3JhZmljb3MvZW1wdHkuZ2lmJy8+PC9URD4KPC90cj4KPHRyPgo8dGQgYWxpZ249 InJpZ2h0Ij48YSBocmVmPSIjdG9wIj48Zm9udCBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj5Q cmluY2lwaW8gUCZhYWN1dGU7Z2luYTwvZm9udD48L2E+PC90ZD4KPC90cj4KPHRyPgo8dGQg YWxpZ249ImNlbnRlciI+PCEtLSBDcmVkaXRvcyAtLT4KPGZvbnQgc2l6ZT0iMSIgZmFjZT0i VmVyZGFuYSI+JmNvcHk7IDE5OTktMjAwMiwKPC9mb250PjxhIGhyZWY9Im1haWx0bzpqYnJh dm9AcmV0ZW1haWwuZXMiPjxmb250CnNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPkpvYXF1aW4g QnJhdm88L2ZvbnQ+PC9hPjxmb250CnNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPiwgPC9mb250 Pgo8YSBocmVmPSJtYWlsdG86bXVsdGl2YWNAaW50ZXJuYXV0YXMub3JnIj48Zm9udCBzaXpl PSIxIgpmYWNlPSJWZXJkYW5hIj5EYW5pZWwgUm9kcmlndWV6PC9mb250PjwvYT48Zm9udCBz aXplPSIxIgpmYWNlPSJWZXJkYW5hIj4sCjxmb250IHNpemU9IjEiCmZhY2U9IlZlcmRhbmEi PkRhdmlkIENhcnJlcm88L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIKZmFjZT0iVmVyZGFuYSI+IHkg PGEgaHJlZj0ibWFpbHRvOmFsZXhtbUBpbmFtZS5jb20iPjxmb250IHNpemU9IjEiCmZhY2U9 IlZlcmRhbmEiPkFsZXggTW9yYWxlczwvZm9udD48L2E+PGZvbnQgc2l6ZT0iMSIKZmFjZT0i VmVyZGFuYSI+PGJyPgpQcm9ncmFtYWNpJm9hY3V0ZTtuIGVuIGNhc3RlbGxhbm8uPGJyPjwv Zm9udD48L3RkPgo8L3RyPgo8L1RBQkxFPgo8L2JvZHk+CjwvaHRtbD=9

1 0

RE: Updates to FFI spec
by Simon Marlow 13 Aug '02

13 Aug '02

> > At the moment, there are two kinds of initialisation done for each > > module: > > Both ELF and DLLs on Windows provide a way of specifying initializers. > > Or, easier yet, since the user is already using the hs_init function, > you could use that. The way you'd do that in ELF is to define a > special section 'hs_initializers'. Every module would contain a > single object in that section: the address of the initializer. (In > gcc you do this by attaching an attribute to the variable. In asm it > is even easier since assemblers directly expose sections to the > programmer.) The linker will do what it does with all sections: > concatenate the pieces from all object files. hs_init would treat the > section as an array of function pointers. I'm sure that the Windows > linker must have a similar mechanism - the main trick is figuring out > what name to give the sections. That's what I meant by a linker set :-) Cheers, Simon

1 0

RE: Updates to FFI spec
by Simon Marlow 13 Aug '02

13 Aug '02

> On 12-Aug-2002, Simon Marlow <simonmar(a)microsoft.com> wrote: > > > > I'd be equally happy (perhaps happier) if the header file spec was > > removed altogether. In a sense, this would leave the > Haskell part of a > > foreign binding even more portable, because it doesn't have > to specify > > the names of header files which might change between platforms. > > This is a C interface we're talking about, right? > > In C, the name of the header file is part of the API. > It doesn't change between different platforms unless > the API changes. > > Specifying the header name is essential if Haskell > implementations are to > ever apply any type-checking to these foreign interfaces. If > they don't, > then in practice I think Haskell programs using the FFI are > likely to be > less portable, and certainly more error-prone, since they will contain > type errors that may cause problems on one platform but not another. Specifying the header name is also essential for certain implementations (eg. GHC). I wan't suggesting not supplying the header file at all, just not supplying it in the foreign declaration and not defining it as part of the standard. But I take your point about the header file(s) being a proper part of the API. Cheers, Simon

1 0

RE: Library archives
by Simon Marlow 13 Aug '02

13 Aug '02

> > > (no, I'm not sure why they're in the C section of the FFI > > spec either). > > Because they are for implementing calls to C code in Haskell > that is compiled to .NET ILX. > > This doesn't mean that I want to necessarily defend them, > but this was the reason for their inclusion. Essentially, > SimonPJ was saying that to compile Haskell including "foreign > import ccall"s to .NET ILX, we need the library spec. > > I am not too fussed about .NET, so don't mind if we nuke the > [lib] specs (as Alastair already did in the CVS version of > the spec). Under .NET each DLL has its own namespace, so the [lib] spec is needed to disambiguate. Since it's a namespace issue, I'd feel better if on .NET the name of the C function took a different form (perhaps <lib>.<function>) and [lib] is removed from the spec. BTW I didn't know the spec was in CVS somewhere... where exactly? Cheers, Simon

3 2

RE: Proposed change to ForeignPtr
by Simon Marlow 12 Aug '02

12 Aug '02

> > What do you expect to happen if the finaliser calls a foreign > > exported function? > > Good question. > > I do not expect that to work on any platform that has difficulty > implementing newForeignPtr (because you could use it to implement > newForeignPtr). > > I don't know if it would be likely to work on GHC. > > I think the spec should say that it is an error or undefined > depending on whether GHC supports reentrant finalizers or not. Yes, it will work in GHC. makeForeignPtr is easily implemented in terms of newForeignPtr, using a foreign import "dynamic". > > That's a tricky one. From the standards point of view, I am > > actually *very* reluctant to introduce new names. On the other > > hand, reusing the old names will lead to a couple of unhappy emails > > from people using the old interface again. > > But only a couple I conjecture. Heh, I distinctly remember several complaints from *you* in the past when things have changed in GHC! Cheers, Simon

2 1