1. 25
  1. 10

    While I appreciate that you are spreading the word, I have objections regarding the presentation.

    It shouldn’t be marked 2018. It isn’t complete, but neither it’s abandoned (see the commit history). It’s open to contributions too.

    If other people participate, it will be completed sooner.

    Note that there’s also live version at https://ocaml-book.baturin.org

    1. 1

      Please excuse me, I regret the error. I don’t seem to be able to edit the title.

      1. 1

        It used to point to the github repo. Now it points to the unedited, outdated blog posts where it started that I kept for the history. What was the motivation for that? ;)

        1. 2

          Just happened to find this page and thought it was interesting. Didn’t mean to point to the wrong resource.

    2. 6

      Shoutout to @dmbaturin, the author of the series.

      1. 2

        I really want to like OCaml, but it has what I see as a fundamental misfeature, and I can’t tell whether I’m holding it wrong or whether there’s a good reason for it that I haven’t found yet. Specifically, partial application monomorphizes the result type.

        For example:

        # let id1 = fun a b -> b;;
        val id1 : 'a -> 'b -> 'b = <fun>
        # let id : 'a -> 'a = id1 "foo";;
        val id : '_a -> '_a = <fun>
        # id;;
        - : '_a -> '_a = <fun>
        # id 1;;
        - : int = 1
        # id;;
        - : int -> int = <fun>

        In my opinion, the type of id shouldn’t be monomorphized just because I happened to use it with a specific type. The fact that it does make it feel really awkward to define functions in a point-free style.

        What am I missing?

        1. 7

          Specifically, partial application monomorphizes the result type.

          Partial application only sometimes monomorphizes the result type. This ‘misfeature’ is caused by the relaxed value restriction, which is required to make the type system sound in the presence of mutation. You can read more about the value restriction in the OCaml manual.

          The fact that it does make it feel really awkward to define functions in a point-free style.

          In my experience, the value restriction is seldom an obstacle to most OCaml code. It’s not particularly common to mix point-free style pure code with code that uses side-effects and mutations—and when it happens, it’s probably a bad idea anyway, in terms of making it difficult to reason about the evaluation order. Plus, OCaml programmers don’t have as much of a desire to make their code point-free as, say, some Haskell folks seem to want to do.

          1. 4

            It’s not generally considered good practice to define functions in point-free style in OCaml, so there you have it.

            Whether this is due to the value restriction you mention or to the language’s general “aesthetics” is up for debate; personally I’ve never found the value restriction to be anything more than a mild annoyance.