10 ms·

After seeing that Facebook's Flow tool was written with an OCaml parser, I was quite impressed by the beauty of its syntax. It makes functional programming feel

After seeing that Facebook's Flow tool was written with an OCaml parser, I was quite impressed by the beauty of its syntax. It makes functional programming feel much less intimidating, compared to Haskell or a Lisp in my opinion, and I can see the parallels to F#. Thanks for sharing this introduction, it was very apropos for me!

tel 12y ago
F# more or less started with OCaml, took some features away, added some others. If you're familiar with F# then OCaml will look natural. Though, that said, if you're familiar with OCaml then Haskell should be rather easy to pick up syntactically.
- jordigh 12y ago
  There's one big difference, huge difference in my opinion, between Haskell and OCaml: OCaml makes monads almost invisible. They're much more in-your-face in Haskell. I'm not sure which one I like better, but it's nice to have a plain ol' for-loop available in OCaml.
  - bad_user 12y ago
    Maybe, but that's not a huge difference, because when working in a language that has monads in it, then one has to get monads (in the same sense that one has to understand iterators in other languages). There's no way around it - thankfully it isn't that complicated, too bad all of these articles flying around make it seem so. The one humongous difference is that Haskell is non-strict and this changes everything.
    - amirmc 12y ago
      I was going to ask whether 'non-strict' means lazy but I decided to look it up first. I thought others might also find it interesting. https://www.haskell.org/haskellwiki/Lazy_vs._non-strict https://www.haskell.org/haskellwiki/Lazy_vs._non-strict
    - thinkpad20 12y ago
      I think Haskell's purity is a more humongous difference than its non-strictness, at least when you're talking about non-performance-critical applications. Laziness can produce unintuitive behavior in a program, and can make certain things harder, but purity is much more "in your face" as a programmer, and a more significant hurdle to beginners -- or at least, it was to me. I agree, though, that as the programmer becomes more sophisticated, the laziness aspect becomes a more significant difference and, ultimately, probably the biggest reason why Haskell will likely never become truly mainstream. Fortunately, there are promising languages out there which are both pure AND strict, such as Idris, Ur and Manticore.
      - dllthomas 12y ago
        Of course, historically, there's the argument that Haskell's purity was motivated by its non-strictness. "Wearing the hair shirt" and all.
        chriswarbo 12y ago
        Well, the motivation was to be pure. Non-strictness removed the temptation to extend the language in non-pure ways, either intensionally or accidentally, for the sake of convenience.
        dllthomas 12y ago
        You're right, of course. Though if they had cheated, the result probably would have been less interesting.
  - ihm 12y ago
    Could you explain what you mean by this? I'd say using monads is way more "in-your-face" in OCaml since you have to explicitly say which monad you're using (via opening a module or what have you) and there's no do-notation. Perhaps you mean that one doesn't need monads as much in OCaml since it's impure and so they aren't required to manage state?
    - technomancy 12y ago
      To be this is a community factor rather than a technical one. You can't talk to a Haskell person for five minutes before they're trying to explain monads to you, (often whether you already understand them or not) and to an OCaml programmer they're just another tool.
      - dllthomas 12y ago
        You're probably talking to the wrong Haskell people :-P
      - tel 12y ago
        I'm fairly sure it's a complete technical one. Haskell's purity enforces effect typing, OCaml doesn't. You can just get more done without monads in OCaml and you have to have built-in syntax for sequencing (e.g. ;).
  - agumonkey 12y ago
    Hi, this is the first time I hear that OCaml embeds monads invisibly ? meaning IO has no special status ? or is there some built-in module ?
    - tel 12y ago
      IO has no special status in OCaml.
  - mercurial 12y ago
    I'd rather say that the big difference is that since OCaml is impure, you're going to run into much less monads in general (though you do have monadic libraries like lwt).
  - tel 12y ago
    That's definitely a big difference: OCaml's impurity. Everything exists in a natural (sort of, see below), invisible monad. Let binding can be both pure and impure since impure statements just return plain values upon execution. Furthermore, this is why you have to use (;) all over the place---it's really just the monadic (>>). Which just goes to show that monads are actually totally natural. Force someone to live in one all of the time and they just forget it's there. The major thing is that such monads don't play nicely with laziness which drove Haskell to develop (partial) purity the way that it did. This plays out in OCaml where you have to explicitly say exactly when you're forcing lazy thunks which lets the sequencing of operations remain clear.
    - seanmcdirmid 12y ago
      > Which just goes to show that monads are actually totally natural. Force someone to live in one all of the time and they just forget it's there. How is that different from saying "mutable state is natural?" I mean, if you don't see the monad, aren't we just right back at imperative programming, or is OCaml implemented with real monads under the cover that make a significant difference to the programming experience? Does it even have a basic effects system?
      - tel 12y ago
        You can build a basic effect system in the same way you do in Haskell (except without typeclasses you need to be more explicit about which monad you're living inside of). Without syntax sugar this is a bit noisier, of course. Also, without typeclasses transformer stacks are difficult and `mtl`-style transformers are impossible (I think). So, you can think of OCaml's semantics as living inside of a monad. Or just do it all implicitly by giving basic semantics to ;. And the way I was speaking I mean to say that "mutable state is natural" too. I don't know that it is universally, but it's certainly something that makes 90% of programmers today feel comfortable.
        seanmcdirmid 12y ago
        Does OCaml actually need to apply special semantics to ; or do those already come with strictness? Thanks for the response BTW, this is one of those things I've always wondered about. > And the way I was speaking I mean to say that "mutable state is natural" too. I don't know that it is universally, but it's certainly something that makes 90% of programmers today feel comfortable. Well, as long as time and change are considered.
  - Dn_Ab 12y ago
    OCaml doesn't so much make monads invisible (except for a technical yet handwavy note on semicolons just as true for C) as make them unnecessary due to being more pragmatic. It's strict and allows mutability when necessary. Of course explicitly recognizing when you're using a monad is extemely powerful and allows elegant formulations of lots of wonderful things like LogicT, probabilistic computation and continuations. Specific instances of monads are definable in most languages in use today, it's when you want to generalize over monads that Haskell stands out. For that you want higher kindedness, Ocaml can simulate them using the module system but it's rather cumbersome. There is a work around described here: https://ocamllabs.github.io/higher/lightweight-higher-kinded-polymorphism.pdf https://ocamllabs.github.io/higher/lightweight-higher-kinded.... The work around is also applicable to the cousin, F#: https://github.com/palladin/Higher/tree/master/src/Higher.Core https://github.com/palladin/Higher/tree/master/src/Higher.Co...
  - gaze 12y ago
    I think you're munging your terminology. Side-effectful computations in haskell are done inside the IO monad. A monad is not in general a thing for side-effectful computation. They are made unnecessary for side-effectful computation in o'caml because of the inherent support for mutability. Indeed side-effectful computation can be represented as a monad, and therefore the ; in ocaml might be interpreted as a bind. Something just needs to satisfy the monad laws in order to be a monad. However, in Haskell the IO monad is explicitly defined. This is very important. The do syntax is sugar over monadic binding them together. In ocaml, sequential computation is simply scheduled sequentially. In haskell, something of type IO () is a VALUE which corresponds to an ACTION which can be RUN. The function which returns the IO action is still pure. It is the outside world which consumes the IO action and performs it. In o'caml, functions are merely impure as in other languages. The function that prints 3 and returns 8 in ocaml has type "int". The function that prints 3 and returns 8 in haskell has type "IO Int"...
  - LeonidasXIV 12y ago
    > OCaml makes monads almost invisible. That is not true at all. If you have worked with any monadic data structure that is not hardcoded into the compiler (like List) for example Lwt you would see how tedious handling monads is. So tedious that not one but four syntax extensions exist to make it less boilerplate heavy (pa_lwt, lwt.ppx, pa_monad, omonad).
pseudonom- 12y ago
Care to elaborate on what you like about its syntax? I can imagine preferring it to Haskell or Lisp, but not thinking it's beautiful.
- glifchits 12y ago
  Looking at a random file in the Flow source [0] (* The entry point *) let rec go content = let env = { file = None; modified = []; line = 0; result = [] } in let lines = split_lines content in start env lines; match List.rev env.result with | [] -> [] | _ :: results -> results (* Skip the text before the first +++ (to make things work with git show) *) and start env = function | [] -> () | line :: lines when String.length line > 4 && String.sub line 0 3 = "+++" -> header env line; modified env 0 lines | _ :: lines -> start env lines Its beautiful to me because its very concise looking, while still using a fair bit of real English, meaningful symbols, and idioms like [] makes an empty array or whatever. I have to admit, much of this is lost on me, but it does feel more accessible than other FP languages. It almost has a Python feel. [0] https://github.com/facebook/flow/blob/master/hack/parsing/format_diff.ml#L67-L83 https://github.com/facebook/flow/blob/master/hack/parsing/fo...
  - sampo 12y ago
    I agree that OCaml syntax is relatively nice, and very readable. But the first line let rec go content = may be problematic for an outsider who doesn't know that let and rec are keywords. It means let recursive function go(content) = ...
    - edwintorok 12y ago
      Looks better with syntax highlighting: https://paste.debian.net/133342/ https://paste.debian.net/133342/
      - deleted 12y ago
        [deleted]

tel 12y ago

F# more or less started with OCaml, took some features away, added some others. If you're familiar with F# then OCaml will look natural. Though, that said, if you're familiar with OCaml then Haskell should be rather easy to pick up syntactically.

jordigh 12y ago
There's one big difference, huge difference in my opinion, between Haskell and OCaml: OCaml makes monads almost invisible. They're much more in-your-face in Haskell. I'm not sure which one I like better, but it's nice to have a plain ol' for-loop available in OCaml.
- bad_user 12y ago
  Maybe, but that's not a huge difference, because when working in a language that has monads in it, then one has to get monads (in the same sense that one has to understand iterators in other languages). There's no way around it - thankfully it isn't that complicated, too bad all of these articles flying around make it seem so. The one humongous difference is that Haskell is non-strict and this changes everything.
  - amirmc 12y ago
    I was going to ask whether 'non-strict' means lazy but I decided to look it up first. I thought others might also find it interesting. https://www.haskell.org/haskellwiki/Lazy_vs._non-strict https://www.haskell.org/haskellwiki/Lazy_vs._non-strict
  - thinkpad20 12y ago
    I think Haskell's purity is a more humongous difference than its non-strictness, at least when you're talking about non-performance-critical applications. Laziness can produce unintuitive behavior in a program, and can make certain things harder, but purity is much more "in your face" as a programmer, and a more significant hurdle to beginners -- or at least, it was to me. I agree, though, that as the programmer becomes more sophisticated, the laziness aspect becomes a more significant difference and, ultimately, probably the biggest reason why Haskell will likely never become truly mainstream. Fortunately, there are promising languages out there which are both pure AND strict, such as Idris, Ur and Manticore.
    - dllthomas 12y ago
      Of course, historically, there's the argument that Haskell's purity was motivated by its non-strictness. "Wearing the hair shirt" and all.
      - chriswarbo 12y ago
        Well, the motivation was to be pure. Non-strictness removed the temptation to extend the language in non-pure ways, either intensionally or accidentally, for the sake of convenience.
        dllthomas 12y ago
        You're right, of course. Though if they had cheated, the result probably would have been less interesting.
- ihm 12y ago
  Could you explain what you mean by this? I'd say using monads is way more "in-your-face" in OCaml since you have to explicitly say which monad you're using (via opening a module or what have you) and there's no do-notation. Perhaps you mean that one doesn't need monads as much in OCaml since it's impure and so they aren't required to manage state?
  - technomancy 12y ago
    To be this is a community factor rather than a technical one. You can't talk to a Haskell person for five minutes before they're trying to explain monads to you, (often whether you already understand them or not) and to an OCaml programmer they're just another tool.
    - dllthomas 12y ago
      You're probably talking to the wrong Haskell people :-P
    - tel 12y ago
      I'm fairly sure it's a complete technical one. Haskell's purity enforces effect typing, OCaml doesn't. You can just get more done without monads in OCaml and you have to have built-in syntax for sequencing (e.g. ;).
- agumonkey 12y ago
  Hi, this is the first time I hear that OCaml embeds monads invisibly ? meaning IO has no special status ? or is there some built-in module ?
  - tel 12y ago
    IO has no special status in OCaml.
- mercurial 12y ago
  I'd rather say that the big difference is that since OCaml is impure, you're going to run into much less monads in general (though you do have monadic libraries like lwt).
- tel 12y ago
  That's definitely a big difference: OCaml's impurity. Everything exists in a natural (sort of, see below), invisible monad. Let binding can be both pure and impure since impure statements just return plain values upon execution. Furthermore, this is why you have to use (;) all over the place---it's really just the monadic (>>). Which just goes to show that monads are actually totally natural. Force someone to live in one all of the time and they just forget it's there. The major thing is that such monads don't play nicely with laziness which drove Haskell to develop (partial) purity the way that it did. This plays out in OCaml where you have to explicitly say exactly when you're forcing lazy thunks which lets the sequencing of operations remain clear.
  - seanmcdirmid 12y ago
    > Which just goes to show that monads are actually totally natural. Force someone to live in one all of the time and they just forget it's there. How is that different from saying "mutable state is natural?" I mean, if you don't see the monad, aren't we just right back at imperative programming, or is OCaml implemented with real monads under the cover that make a significant difference to the programming experience? Does it even have a basic effects system?
    - tel 12y ago
      You can build a basic effect system in the same way you do in Haskell (except without typeclasses you need to be more explicit about which monad you're living inside of). Without syntax sugar this is a bit noisier, of course. Also, without typeclasses transformer stacks are difficult and `mtl`-style transformers are impossible (I think). So, you can think of OCaml's semantics as living inside of a monad. Or just do it all implicitly by giving basic semantics to ;. And the way I was speaking I mean to say that "mutable state is natural" too. I don't know that it is universally, but it's certainly something that makes 90% of programmers today feel comfortable.
      - seanmcdirmid 12y ago
        Does OCaml actually need to apply special semantics to ; or do those already come with strictness? Thanks for the response BTW, this is one of those things I've always wondered about. > And the way I was speaking I mean to say that "mutable state is natural" too. I don't know that it is universally, but it's certainly something that makes 90% of programmers today feel comfortable. Well, as long as time and change are considered.
- Dn_Ab 12y ago
  OCaml doesn't so much make monads invisible (except for a technical yet handwavy note on semicolons just as true for C) as make them unnecessary due to being more pragmatic. It's strict and allows mutability when necessary. Of course explicitly recognizing when you're using a monad is extemely powerful and allows elegant formulations of lots of wonderful things like LogicT, probabilistic computation and continuations. Specific instances of monads are definable in most languages in use today, it's when you want to generalize over monads that Haskell stands out. For that you want higher kindedness, Ocaml can simulate them using the module system but it's rather cumbersome. There is a work around described here: https://ocamllabs.github.io/higher/lightweight-higher-kinded-polymorphism.pdf https://ocamllabs.github.io/higher/lightweight-higher-kinded.... The work around is also applicable to the cousin, F#: https://github.com/palladin/Higher/tree/master/src/Higher.Core https://github.com/palladin/Higher/tree/master/src/Higher.Co...
- gaze 12y ago
  I think you're munging your terminology. Side-effectful computations in haskell are done inside the IO monad. A monad is not in general a thing for side-effectful computation. They are made unnecessary for side-effectful computation in o'caml because of the inherent support for mutability. Indeed side-effectful computation can be represented as a monad, and therefore the ; in ocaml might be interpreted as a bind. Something just needs to satisfy the monad laws in order to be a monad. However, in Haskell the IO monad is explicitly defined. This is very important. The do syntax is sugar over monadic binding them together. In ocaml, sequential computation is simply scheduled sequentially. In haskell, something of type IO () is a VALUE which corresponds to an ACTION which can be RUN. The function which returns the IO action is still pure. It is the outside world which consumes the IO action and performs it. In o'caml, functions are merely impure as in other languages. The function that prints 3 and returns 8 in ocaml has type "int". The function that prints 3 and returns 8 in haskell has type "IO Int"...
- LeonidasXIV 12y ago
  > OCaml makes monads almost invisible. That is not true at all. If you have worked with any monadic data structure that is not hardcoded into the compiler (like List) for example Lwt you would see how tedious handling monads is. So tedious that not one but four syntax extensions exist to make it less boilerplate heavy (pa_lwt, lwt.ppx, pa_monad, omonad).

pseudonom- 12y ago

Care to elaborate on what you like about its syntax? I can imagine preferring it to Haskell or Lisp, but not thinking it's beautiful.

glifchits 12y ago
Looking at a random file in the Flow source [0] (* The entry point *) let rec go content = let env = { file = None; modified = []; line = 0; result = [] } in let lines = split_lines content in start env lines; match List.rev env.result with | [] -> [] | _ :: results -> results (* Skip the text before the first +++ (to make things work with git show) *) and start env = function | [] -> () | line :: lines when String.length line > 4 && String.sub line 0 3 = "+++" -> header env line; modified env 0 lines | _ :: lines -> start env lines Its beautiful to me because its very concise looking, while still using a fair bit of real English, meaningful symbols, and idioms like [] makes an empty array or whatever. I have to admit, much of this is lost on me, but it does feel more accessible than other FP languages. It almost has a Python feel. [0] https://github.com/facebook/flow/blob/master/hack/parsing/format_diff.ml#L67-L83 https://github.com/facebook/flow/blob/master/hack/parsing/fo...
- sampo 12y ago
  I agree that OCaml syntax is relatively nice, and very readable. But the first line let rec go content = may be problematic for an outsider who doesn't know that let and rec are keywords. It means let recursive function go(content) = ...
  - edwintorok 12y ago
    Looks better with syntax highlighting: https://paste.debian.net/133342/ https://paste.debian.net/133342/
    - deleted 12y ago
      [deleted]