3 ms·

> I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story Not really. Here’s an example of writin

by mietek 12y ago

> I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story Not really. Here’s an example of writing shared libraries for C in Haskell: https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example

nostrademons 12y ago
The "called from C" case isn't the interesting one, even though it's what the grandparent mentioned. It's the "called from a scripting language" case. You can call Haskell or Ocaml or even Java code from within CPython or Matz Ruby. However, if you do this, you bring along an entirely different runtime system and memory layout. Usually this means that you face some very odd memory management bugs and lose any speed advantage you gain as soon as you have to marshal objects across the language boundary.
- mietek 12y ago
  Interesting opinion. What are the applications?
  - steveklabnik 12y ago
    One of the first production deployments of Rust is such an application: https://www.skylight.io/ https://www.skylight.io/ Their Ruby gem is actually written in Rust.
  - geofft 12y ago
    Servo is doing some things to outsource GC to JavaScript, because the DOM (and therefore object lifetime tracking) needs to interact tightly with both JavaScript and native code: https://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
geofft 12y ago
Cool! What are the limitations here? I'm quite a bit surprised you're able to make this work properly with pthreads... I somehow thought the GHC runtime will automatically multithread pure functions that can be evaluated in parallel. How much can you call back into C from a Haskell function and have things behave reasonably? I suppose there's actually a bit of advantage in that such a thing would need to return a type in the IO monad, but I'm super unfamiliar with the GHC runtime.
- mietek 12y ago
  I am not aware of any limitations, except for the static linking caveat noted in the README. The build process is also a bit involved; see the Makefile for details. My use case involves shipping Haskell plugins for C programs to end-users, without requiring any Haskell to be installed. Hence, statically linking all Haskell libraries into the plugin binary. On Linux, this is slightly inconvenient, as GHC packages are not usually compiled with -fPIC, so some recompilation is in order. On OS X, all code is always position-independent. As for your other question — calling C from Haskell is very easy, and there is a lot of examples. http://hackage.haskell.org/packages/search?terms=bindings http://hackage.haskell.org/packages/search?terms=bindings
  - geofft 12y ago
    Sure, I've played with Haskell-to-C FFI before (a very tiny bit). I'm curious if there are some complications with C->Haskell->C, but maybe not. I'm strongly thinking that Haskell has an advantage here because "well, what if the Haskell function fails" or "well, what if the C function fails" is well-defined by the type system.... Can you return a pointer/reference to a Haskell object to C on one thread, and then call Haskell functions on it from another C thread?
    - mietek 12y ago
      Yes. You can use stable pointers for this purpose. A stable pointer is a reference to a Haskell expression that is guaranteed not to be affected by garbage collection, i.e., it will neither be deallocated nor will the value of the stable pointer itself change during garbage collection (ordinary references may be relocated during garbage collection). Consequently, stable pointers can be passed to foreign code, which can treat it as an opaque reference to a Haskell value. https://hackage.haskell.org/package/base-4.7.0.1/docs/Foreign-StablePtr.html https://hackage.haskell.org/package/base-4.7.0.1/docs/Foreig...

by mietek 12y ago

nostrademons 12y ago

The "called from C" case isn't the interesting one, even though it's what the grandparent mentioned. It's the "called from a scripting language" case. You can call Haskell or Ocaml or even Java code from within CPython or Matz Ruby. However, if you do this, you bring along an entirely different runtime system and memory layout. Usually this means that you face some very odd memory management bugs and lose any speed advantage you gain as soon as you have to marshal objects across the language boundary.

mietek 12y ago
Interesting opinion. What are the applications?
- steveklabnik 12y ago
  One of the first production deployments of Rust is such an application: https://www.skylight.io/ https://www.skylight.io/ Their Ruby gem is actually written in Rust.
- geofft 12y ago
  Servo is doing some things to outsource GC to JavaScript, because the DOM (and therefore object lifetime tracking) needs to interact tightly with both JavaScript and native code: https://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...

geofft 12y ago

Cool! What are the limitations here? I'm quite a bit surprised you're able to make this work properly with pthreads... I somehow thought the GHC runtime will automatically multithread pure functions that can be evaluated in parallel. How much can you call back into C from a Haskell function and have things behave reasonably? I suppose there's actually a bit of advantage in that such a thing would need to return a type in the IO monad, but I'm super unfamiliar with the GHC runtime.

mietek 12y ago
I am not aware of any limitations, except for the static linking caveat noted in the README. The build process is also a bit involved; see the Makefile for details. My use case involves shipping Haskell plugins for C programs to end-users, without requiring any Haskell to be installed. Hence, statically linking all Haskell libraries into the plugin binary. On Linux, this is slightly inconvenient, as GHC packages are not usually compiled with -fPIC, so some recompilation is in order. On OS X, all code is always position-independent. As for your other question — calling C from Haskell is very easy, and there is a lot of examples. http://hackage.haskell.org/packages/search?terms=bindings http://hackage.haskell.org/packages/search?terms=bindings
- geofft 12y ago
  Sure, I've played with Haskell-to-C FFI before (a very tiny bit). I'm curious if there are some complications with C->Haskell->C, but maybe not. I'm strongly thinking that Haskell has an advantage here because "well, what if the Haskell function fails" or "well, what if the C function fails" is well-defined by the type system.... Can you return a pointer/reference to a Haskell object to C on one thread, and then call Haskell functions on it from another C thread?
  - mietek 12y ago
    Yes. You can use stable pointers for this purpose. A stable pointer is a reference to a Haskell expression that is guaranteed not to be affected by garbage collection, i.e., it will neither be deallocated nor will the value of the stable pointer itself change during garbage collection (ordinary references may be relocated during garbage collection). Consequently, stable pointers can be passed to foreign code, which can treat it as an opaque reference to a Haskell value. https://hackage.haskell.org/package/base-4.7.0.1/docs/Foreign-StablePtr.html https://hackage.haskell.org/package/base-4.7.0.1/docs/Foreig...