Haskell for OCaml programmers | Hacker News Reader

Haskell for OCaml programmers

science.raphael.poss.name

54 pointsnetworked13 comments

Avoiding using the "M-word" and pretending they're just "recipes" is going to cause confusion when these new Haskell programmers see someone using the list monad.

I don't understand this almost religious need to rename things. It's a monad, call it a monad. People don't know what it is? Well, explain what it is to them. If you hide the real name from them they're going to be confused later.

It's also very strange and unhelpful to tell people that ; in Haskell ("inside a do block") and OCaml are equivalent. The closest equivalent thing in Haskell is (>>), which sequences two monad operations together, discarding the result of the first. Alongside that, there's (>>=), which sequences two monad operations and passes the result of the first operation to your function. From there, you can then introduce do-notation, which is just syntactic-sugar. This way, you avoid newcomers being confused about what `do` does: https://wiki.haskell.org/Do_notation_considered_harmful#Dida...

So `p1 (); p2 ()` would be better translated into Haskell as `main = p1 >> p2`. And in `main = do putStrLn "world"`, the `do` is redundant.

One of the reasons I've seen a lot of people move from OCaml to Haskell is the "holy grail of multi core domination". In OCaml, if you want control over multiple cores, you need to scale via the process model or wait for OCaml 4.03.

Some people have just moved on.

Why not move to F#?

what's the state of mono on Linux ?

I’ve been using it on OS X, but Linux support should just work, too. Development is quite active; 4.0 came out recently, with a number of stability and performance improvements.

Pillars of Eternity work on Linux without any kind of installation (or other problems, in my experience) by bundling Mono runtime with the game. I'd say it's pretty solid (well... after the 1.05 patch, but that's a different matter) and works well.

Well, I am using it mostly for CLI applications where multi core is not a problem, but the type system is a bliss. An we can just compile to native or bytecode and deploy a single file (just like Go). Does Haskell support CSP (channels, cooperative threads)?

The runtime is SMP-capable and lightweight threads are preemptable, multiplexed on top of epoll (or kqueue) based event loops. So it's a preemptive N:M model. Haskell threads basically try to behave like OS threads as much as possible (with semantics that look like they're blocking) but they have a lot better cost model overall, so you don't need to do manual callback-based programming. It's pretty nice.

There are really dozens of concurrency abstractions you can choose from, and yes, CSP-style programming is an option, available as a library: http://hackage.haskell.org/package/chp - and common abstractions like MVars (which are essentially simple, concurrent 1-place queues) can get you a long way even without that.

There are other libraries for more specific needs; like graph/dataflow based parallelism, array parallelism, GPU-based programming, DSLs for image processing, etc etc.

All that said I'm very happy and hopeful to see OCaml 4.03 adopt multicore support. OCaml has an excellent, robust and lightweight toolchain and implementation, and is very straight-forward and powerful out of the box. It's not my personal cup of tea, but we'd be worse off if they weren't here.

Thank you for the detailed response.

OCaml is not my cup of tea either, but it is really interesting to learn it. If you have any ML like experience than I guess it is less interesting though. The toolchain is great this was one reason I decided to try it out.

Yeah, GHC’s runtime provides lightweight threads (forkIO) as well as OS threads (forkOS). The runtime and various libraries provide a wealth of parallelism and concurrency primitives—Chan, MVar, STM, TVar, &c.

Concurrent programming in Haskell is delightful. It gave me a better understanding of how to do it in imperative-land, too.

A question: Why ML family languages need `rec` for recursive functions while other languages do not?

http://stackoverflow.com/questions/9325888/why-does-ocaml-ne...

and

http://stackoverflow.com/questions/900585/why-are-functions-...

They don't. Standard ML has the `fun` keyword which does what you want. OCaml has it, but it could easily be for legacy reasons - it's hardly a sticking point!

Reply on news.ycombinator.com