Functional Programming in OCaml | Hacker News Reader

Functional Programming in OCaml

cs.cornell.edu

258 pointsgstipi58 comments

Open articleView on HN

ReasonML is Facebook’s OCaml for JavaScript.

https://reasonml.github.io/

They have used it extensively:

https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

With impressive results:

“ Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! *”

If I get it right (from posts I've seen before and the docs on the project [1]) Reason is not really "OCaml for JavaScript" but just a parser for a more appealing, mostly compatible, syntax for the OCaml. So one should be able to compile to the same targets as with traditional OCaml.

Re: Mostly compatible: I remember there were certain things that were not easily expressible with Reason (but available in the OCaml syntax) a few years ago, not sure if it is still the case.

Subjective: OCaml syntax is definitely on the weird side, although I would not call it ugly. This coming from someone who enjoys writing clojure and xslt, go figure :-p.

1: https://github.com/facebook/reason/blob/master/src/README.md...

Js_of_ocaml [1] is a good alternative to BuckleScript for standard OCaml (non-Reason).

For example, it works well with Core_kernel [2] and Async_kernel [3] to provide high-level functionality that is cross compatible between Unix applications and browser applications.

[1] https://github.com/ocsigen/js_of_ocaml

[2] https://github.com/janestreet/core_kernel

[3] https://github.com/janestreet/async_kernel

To be clear, Bucklescript also works with standard OCaml (because Reason is just an alternative surface syntax).

Js_of_ocaml works fine with Reason, though.

BuckleScript (https://bucklescript.github.io/) is used for using OCaml to output JavaScript. Reason can target native just like vanilla OCaml syntax can.

Oh, I was browsing BuckleScript's history and for a minute thought evmar [1] was involved (author of the ninja build system) [2].

But I think evmar's commits are just ninja commits. First BS commit: [3]. Almost looks as if the author of BuckleScript maybe forked the ninja repo and started to work in BuckleScript from there.

Why would anybody do that? Such a mystery...

1: https://github.com/BuckleScript/bucklescript/graphs/contribu...

2: https://github.com/ninja-build/ninja

3: https://github.com/BuckleScript/bucklescript/commit/a626ee8b...

yet ml use in the industry is thin, alas quality goes with patience

Is that with the same team or with a new one? Maybe the reason is the new team and full rewriting of the initial version and not the new language...

Very nice practical and modern textbook for OCaml. I were using it last year to teach this subject at my school. Here are my additional notes and exercises, if you are interested: https://a-nikolaev.github.io/fp/

I don't know why they felt they had to mess with OCaml's syntax - one of the nicest around AFAIC. With F#, even MS didn't feel like they had to add extra braces and other baggage and change keywords ("match" to "switch ()", etc.) to make C# programmers have an easier first ten minutes of transition time.

I think F# cleaned up a lot of OCaml’s syntactic oddities nicely, though I could do without the off-side rule.

F# supports OCaml syntax as well, via a compiler pragma.

f# has diverged away from ocaml enough that the small fact that a tiny subset of it is compatible with ocaml is just a trivia fact.

I’m aware. #light “off”

Agreed! and the approach to operator overloading is much more pragmatic.

I think Haskell's or F#'s syntax is a lot better, OCaml has a lot of edge cases that require parens. OCaml is an old language and it really shows in the syntax. I personally think Reason's cleanup of strange parsing rules that OCaml has is a good step forward, though changing match to switch is kind of annoying, I must admit.

There's a few legitimate issues with OCaml syntax that have been fixed by Reason at least. E.g. `match`/`if` not having an `end` means you need to use parens or `begin`/`end` to nest match and have ; inside of an `if` body. There's also some ambiguity between functional `if` and imperative `if` in some situations.

Despite that, Reason adds semicolons and braces to OCaml; presumably this was to make it have a more JavaScript aesthetic for on-boarding (ignoring JS's ASI)?

Explicit opening and closing structures help locate and explain errors better.

In an absence of an entirely obvious, unambiguous, commonly known way of formatting, it's helpful.

I'm not sure to understand how it helps. Are you talking about parsing errors ?

As for formatting, if you manage to get an AST, what would be made easier by braces ?

Yes, parsing errors. In a number of cases you can legitimately continue to interpret a text well past the missing closing token, and signal an error in a place which does not seem related.

If you already have a correct AST, you can render it whatever way you want.

Because OCaml aware editors/IDE don't exist.

Merlin works really well in my experience for both ReasonML and OCaml. Also there's LSP support so OCaml/ReasonML have as much editor support as any other language.

I was being sarcastic....

Are you referring to Reason? I don't see anything related to messing OCaml syntax in the OP.

"Reason, also known as ReasonML, is a syntax extension and toolchain for OCaml created by Jordan Walke at Facebook.[2] Reason offers a syntax familiar to JavaScript programmers, and transpiles to OCaml.[3]"

https://en.wikipedia.org/wiki/Reason_(syntax_extension_for_O...

got it, I was just confused since usually top level comments refer to the original post, which in this case is a Textbook for OCaml that doesn't mention Reason anywhere afaict

Sorry, my bad - I meant to reply to @melling, not the top-level

Well, with F# they did change some significant things e.g. type parameter syntax. Anyway, the point of Reason is that some people just won't even look at OCaml syntax. They just won't, that's the way it is. Reason allows us to onboard those people now, get them to see the benefits of the language, and perhaps later even come around to preferring the OCaml syntax.

An great course and a very good professor. I'm glad they've compiled the course into an ebook. It's the only way I can think of FP, so I'm glad I can know point people to the same source I learned it from.

It would be quite awesome if they made it fully interactive; in the vein of several other textbooks that have been shared on HN recently.

I am working on two projects in one that may be similar to what you’re thinking. I really like the way the University of Waterloo’s CS Python tutorial [1] is done, so I’m trying to get a little bit of comfort with web development, and I decided I wasn’t happy just being familiar with Haskell and wanted to get into ML... So I’m slowly going through the 2019 version of this book and inserting dummy formatted JS input blocks with the intention of hooking them up to an online interpreter. I doubt I’ll get all the way through the text, but if I want messing with fancy formatting and trying to learn the web design aspects (and therefore messing around with CSS waaaay too much) it doesn’t seem like an insurmountable task.

—- Also, the responsive design of the book works pretty well on iOS, and that has been a rarity in this area from my experience.

[1] https://cscircles.cemc.uwaterloo.ca/

which textbooks are interactive like that?

Two that I know are SICP[0] and Eloquent Javascript[1]

[0] https://sicp.comp.nus.edu.sg/ [1] https://eloquentjavascript.net/

If you want to access RESTful APIs via OCaml, you may consider using OpenAPI Generator to generate the OCaml client automatically instead of manually creating one. Here are 3 simple steps to do so:

1. Download the OpenAPI Generator CLI Java JAR (https://repo1.maven.org/maven2/org/openapitools/openapi-gene...)

2. Rename the JAR as "openapi-generator-cli.jar"

3. Run the following command to generate an OCaml API client for the Petstore API (https://raw.githubusercontent.com/OpenAPITools/openapi-gener...):

Mac/Linux:

$ java -jar openapi-generator-cli.jar generate -g ocaml -i https://raw.githubusercontent.com/OpenAPITools/openapi-gener... -o /var/tmp/ocaml/

Windows:

$ java -jar openapi-generator-cli.jar generate -g ocaml -i https://raw.githubusercontent.com/OpenAPITools/openapi-gener... -o C:\tmp\ocaml

If you've any feedback or question, please let us know via https://github.com/OpenAPITools/openapi-generator/issues/new

HN thread on 2019 edition: https://news.ycombinator.com/item?id=19292067

> Java didn't have generics until version 5 in 2004; the ML family had it in 1990.

I thought Standard ML had it in the 70's (!)

Yes, 1975 IIRC. Standard ML was published in 1990, so that is probably the source of the confusion.

It's a bit sad that the foundations of modern programming languages were basically known by 1975 (either via Standard ML or Scheme) but the majority of languages in common use (mostly of a 1990s vintage) didn't learn those lessons. Thankfully that seems to be changing with more recent languages (Go being the exception).

And CLU.

Having researched a bit in the 60's and 70's systems programming languages, I would assert that the same issues with Go apply to C (language design vs existing competition), and they only got lucky because Bell Labs was forbidden to profit from UNIX.

As I don't have a lot of time to investigate at this moment - is this intended to be a generally-standalone guide that one could use to learn OCaml? I'm guessing not, since it doesn't seem to dive in too deep into any subject, just giving a very broad overview.

If you want something more in-depth about OCaml itself, http://dev.realworldocaml.org/ is a good resource.

Any news on how the 2nd edition is going on?

It's totally usable and preferable in its beta format to the first edition. The first edition is pretty out of date with current practice.

Thanks!

Learn OCaml in Y minutes: https://learnxinyminutes.com/docs/ocaml/

I haven't used OCaml in a couple of years. has the stdlib story been improved/standardized? is there still the whole async vs jwt problem or did jwt finally win out?

I think i remember that there wasn't a good web framework, and that the existing popular one had a memory leak.

I was learning from a book (Real World OCaml, i think) and it kept pushing jane street libs like Async and Core.

There may not be that many people doing web development in OCaml directly (Reason ML may be changing this) but it is do-able. Read 'A Lightweight OCaml Webapp Tutorial' - https://shonfeder.gitlab.io/ocaml_webapp/ for a up to date example of an OCaml web stack.

Reason uses the OCaml to Javascript compiler Bucklescript to make OCaml more accessible for web programming. Listen to the podcast 'Reason Town' - https://player.fm/series/reason-town to hear professionals talking about their experience with it.

Most of the issues go away if you use Async and Core (or Base these days) since it is a very good and rather complete standard library and a thoughful Async implementation.

The issue with the web framework still stands. Not many people do web development in OCaml so the support is rather sparse.

Yaron Minsky is one of the author of Real World OCaml, and is the one that brought OCaml to Jane Street so that may be why there's pushing these libs.

Do you mean LWT?

Ah. Yes.

How does OCaml compare with haskell?

* Ocaml's more straightforward and conventional - it's impure, you can mutate with abandon, it's eagerly evaluated for more predictable performance, no one's doing wild stuff with arrows or profunctor lenses or f-algebras or whatever. All this could be either a pro or a con, depending on your perspective.

* Ocaml has an extremely powerful module system that puts that of almost every other language, including Haskell's, to shame.

* Ocaml also has a very powerful object system that goes unused 95% of the time, but could potentially be useful for that other 5%; there's nothing comparable in Haskell.

* Ocaml has no ad-hoc polymorphism, whereas Haskell has typeclasses. The module system substitutes for this in many cases, but it's arguably less ergonomic. In other cases you just need to, say, use different operators to add floats than integers, which is definitely less ergonomic.

* Ocaml has comparable - probably superior - single-threaded performance (very good), but unlike Haskell there's no real parallelism story to speak of. Multicore support has been in the works for over five years and still hasn't arrived.

* Ocaml has a smaller community and ecosystem. Yes, smaller than Haskell.

* As a matter of personal opinion, I prefer Ocaml's straightforward and widely-loathed syntax to Haskell's weird, whitespace-sensitive one.

Ocaml does not make any effort to control impure code or mutability. The type system is not as powerful, but the powerful module system takes up some of the slack. Lots of things that are really convenient in Haskell (like point-free function composition) work poorly or not at all in OCaml due to constraints imposed by the existence of impure mutable references. The OCaml runtime is pretty primitive compared to Haskell’s, especially around stuff like concurrency. GHC has a world-class concurrency story and OCaml barely has support for multiple OS-level threads. OCaml uses tagged pointers for boxing, which means you have weird stuff like integers being 63 bits instead of 64. Haskell uses bitmasks on heap objects to avoid that.

Subjectively, I think OCaml is a huge improvement over, say, Java, but if you’re deciding between learning one of OCaml or Haskell in 2020 I think Haskell is the better option for most people.

I don't consider OCaml and Haskell to be really comparable. I love statically typed FP and have professional experience with OCaml, Haskell, and Scala and Haskell is significantly different than the other two (also much different than F#). I've personally never found Haskell's encoding of mutability or impurity into the type system to be of any real benefit. Most of the time your impurity is coming from logging, networking, or interacting with files or a db; in which case, it's entirely obvious what's going on. Other times, you have a pure function that's implementation is unpure, which is also obvious on what's going on. In any case, if you're programming in good FP-style all Haskell is providing is a bunch of headaches around finding the write way to make all your type annotations match up: it's kind of a annoying experience when you're just trying to get something done.

I think Haskell's a good way to start learning functional programming because it really beats the habit of loops and mutability out of you real fast by making the functional way easier. But if you're already an experienced FP programmer, less restrictive languages are better.

What makes Haskell interesting is all the crazy optimizations it can do since the compiler has so much information about the program. It would be really cool if other languages had a "pure" annotation or keyword that signified the function has a pure interface. This could dramatically improve the performance of a lot of Scala/F#/OCaml code.

I’ve put thousands of hours into both Haskell and Ocaml, so I feel like I have a pretty good understanding of how both affect my development process.

> I've personally never found Haskell's encoding of mutability or impurity into the type system to be of any real benefit.

I find it completely indispensable for large codebases, especially codebases I didn’t write.

> Most of the time your impurity is coming from logging, networking, or interacting with files or a db; in which case, it's entirely obvious what's going on.

Maybe you’re a genius or something, but to me (and most people) it’s not “entirely obvious what’s going on” when large codebases use impure side-effectful semantics in a way that’s not clear from the types.

> Other times, you have a pure function that's implementation is unpure, which is also obvious on what's going on.

Once again, it is not at all obvious. And a very large fraction of the time, that “pure function with an impure implementation” isn’t actually so pure after all, and either leaks mutable semantics or behaves badly (e.g. if used in a multithreaded way). Haskell actually does have a real solution for this in the form of the ST monad. You can write impure things and prove (using the type system) that they have pure semantics. I’m not aware of any other language offering this.

> In any case, if you're programming in good FP-style all Haskell is providing is a bunch of headaches around finding the write way to make all your type annotations match up

Not only are type annotations optional (and usually trivial), but you can get the compiler to write them for you interactively e.g. with holes. In any case, this is never a problem in practice for “business logic” code. I’ve only really seen this come up e.g. when writing lenses by hand (i.e. rarely).

> it's kind of a annoying experience when you're just trying to get something done.

The point where the cognitive overhead introduced by Haskell’s type system is worth the payoff compared to, say, Python, is about 1-200 lines in my experience.

> But if you're already an experienced FP programmer, less restrictive languages are better.

The only “improvement” that you’ve cited so far is that “less restrictive languages” let the programmer be architecturally lazy, which I don’t think is really an improvement.

> It would be really cool if other languages had a "pure" annotation or keyword that signified the function has a pure interface.

If this were preferable, then Haskell programmers could just write everything in IO and selectively factor things out into pure functions. The fact that no one does this is, I think, telling.

The OCaml story for concurrency is good, maybe you were thinking of parallelism? Support there is ongoing in the 'multicore' project.

For concurrency, LWT and Async are both mature and used in production.

> I think OCaml is a huge improvement over, say, Java,

That got a smile from me, given that OCaml is older than Java.

Reply on news.ycombinator.com