On 11-Oct-2002, George Russell <[EMAIL PROTECTED]> wrote: > I think we should remember that the FFI standard has to address various > audiences > (1) those who want to implement portable code in just FFI + Haskell98. > This group does not have access to functions for conveniently manipulating > mutable state, therefore Alastair's problem with IORefs will not be a problem > for them. However Haskell inside finalizers will at any rate not harm them
This argument is invalid, because those who want to implement portable code in just Haskel98 + FFI will very quickly use the FFI to implement IORefs or something similar. > Consider someone who, say, calls out from Haskell to Java (to do funny > graphics, say) and writes a finalizer which calls Java code. At the same time, they > also want to do some completely separate pure computation in Haskell, which is made > available to Java. Since Java at least does have preemptive concurrency, while > it is running at all, it is perfectly possible that Java will call the Haskell >computation > while the Java finalizer is running. You want a license to make the roof fall in at >this > point; I don't think you should have it. If you have a non-thread-safe Haskell implementation, and you try to call it from two different threads without protecting this somehow, then the roof *will* fall in at least some of the time. This follows directly from the definition of "non-thread-safe". So you want to disallow non-thread-safe Haskell implementations from supporting the FFI? -- Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
