views:

413

answers:

3

By "concurrency" I mean lightweight processes like Erlang's actors and concurrent GC aimed to make such a processes work smoothly.

It would be very cool if INRIA got rid of those drawbacks of the current OCaml implementation to make OCaml more prepared for the multicore future.

P.S. F# isn't what I'm looking for.

+4  A: 

no

I cannot be more concise without reproducing his explanation. It speaks for itself. Yes, this is from 2002, but I haven't heard him sway on the issue, and from the text, it doesn't seem probable at all that he would back down from these goals.

For current developments on concurrent functional programming, possibly MPI solutions (with ocaml bindings) might be a solution to your problem. Obviously this is not shared memory parallelism. There is also concurrent ML.

nlucaroni
I'm not prepared to dig into the archives just now, but I'm sure there have been more recent threads where similar sentiments have been expressed. INRIA is focused on supported the OCaml language as is, not pushing forward with big new features like LWP or a concurrent runtime. Isn't that partly the point of Jon Harrop's HLVM?
Chris Conway
ocaml4multicore is available (with limitations), see: http://www.algo-prog.info/ocmc/web/
nlucaroni
+2  A: 

There is J&oCaml, which is …

Objective Caml plus (&) the join calculus, that is, OCaml extended for concurrent and distributed programming.

Jörg W Mittag
But even with JoCaml you need to explicitly call fork if you want to use multiple cores.
aneccodeal
+1  A: 

It seems that Jane Street has funded a project for adding Concurrent GC to OCaml

Mehdi Asgari
That culminated in OCaml4Multicore but it is not very useful because allocation seriously damages scalability and allocation is practically unavoidable in OCaml due to the lack of value types.
Jon Harrop