I'm surprised that better threading wasn't mentioned. As I understand it, OCaml has threads but parallelism isn't possible. That is, although you can have multiple threads, only one can execute at a time.
back
2 comments
#5 of Build Tools and Runtime would cover that (encapsulating all global state into a runtime context). The ongoing multicore work at OCamlPro is taking this approach [1].
Erlang-style actors or lightweight processes would be my dream multicore scenario (no more monads for concurrent IO!), but that's likely too difficult to graft onto the current runtime, which is otherwise extremely well-done.
Also, I'd really like checked exceptions. The omission of checked exceptions has always struck me as strange, given the emphasis on compile-time checking. Considering how fast exceptions are in OCaml, it seems like a bit of a missed opportunity -- it is faster to use exceptions for control flow [2] than matching on variants (such as Option), which usually involve an extra allocation + dereference, IIRC.
[1] http://www.ocamlpro.com/pub/multi-runtime.pdf.tar.gz
[2] Odd as it may sound, it's encouraged to use exceptions as a control-flow construct in OCaml, but that is falling out of favor in modern code as far as I can tell.
Checked exceptions are possibly the worst feature of Java.
Now it may be a good idea to have an optional tool for checking exceptions -- in fact, one exists already, but I can't recall the name of it. But please don't make this mandatory unless you avoid the mistakes of Java.
Checked exceptions are possibly the worst feature of Java.
Why? I absolutely hate C++ codebases where all of a sudden you get yet another type of exception that was not documented, possibly because the exception was thrown ten functions down (up) the stack.
In Java, at the very least you know what to expect and can prepare for it. Unfortunately, even there people try to avoid exceptions by throwing classes that derive from RuntimeException.
Given that Java has no sum types, checked exceptions are really the next best thing.
You can still call Unix.fork, and do threading the C way, although obviously it's not as convenient as real threading support.
Here's an interesting page discussing the current effort to develop a multicore runtime: https://github.com/ocamllabs/compiler-hacking/wiki/Multicore...
That's a good point, and one I hadn't thought of. I wonder what it would take to wrap Unix.fork into a threading library to make threads more convenient?
There are apparently some such libraries already. I haven't used any, but they seem to all use process-level threading; there's no lightweight threading library (like Lwt) that uses real threads. Actually, I'm wrong; turns out it is possible to delegate Lwt threads to system threads: http://ocsigen.org/lwt/api/Lwt_preemptive. This model doesn't seem to allow communication between them, however.
1.http://projects.camlcity.org/projects/dl/ocamlnet-3.3.0test1...
2.http://www.dicosmo.org/code/parmap/