Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why ML/OCaml are good for writing compilers (1998)

flint.cs.yale.edu

Post reply on HN
Print view View original

21–30 of 151 posts

Re: Why ML/OCaml are good for writing compilers (1998)

#21

Post by nv-vn »

ue_ wrote: post #15
Dangeranger wrote: post #3

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis…

I've heard the concurrency situation with OCaml isn't very good, though I know nothing about that. Weirdly, this kind of bias and the idea that it doesn't have as many libraries for my particular domain (web programming) has put me off it, as much as I'd like to use it. Using functional languages without Lisp-like macros will always be sort of weird to me, like I'm missing out on something.

Just to clarify, it's not concurrency that's the issue but parallelism. You can write nice concurrent code pretty easily, but writing code that runs on multiple cores is still a problem. Also, if you're interested in using OCaml for web programming, there is some pretty cool stuff you might wanna check out [1] [2] [3]. That said, there's no great solution to the lack of macros :/

[1] https://github.com/dannywillems/ocaml-for-web-programming

[2] https://github.com/rizo/awesome-ocaml#web-development

[3] https://facebook.github.io/reason/ [2]

Re: Why ML/OCaml are good for writing compilers (1998)

#22

Post by throwaway7645 »

poizan42 wrote: post #16
throwaway7645 wrote: post #5

Earlier quoted context omitted.

Crappy windows support for OCaml. F# is similar to OCaml, but is very difficult for beginners and those not familiar with .NET. I also don't see a lot of beginner material for OCaml.

At computer science at the University of Copenhagen F# has been used for the introduction courses the past couple of years, which as far as I know has been a big success, so I'm doubtful of it not being beginner friendly

Mileage is probably not representative when you're in a university setting being taught by professors in an intro course versus a professional trying to use a multitude of the data science libraries and having trouble tying it together. Python has a zillion books published and a large percentage of them are beginner oriented. F# has only a few books and they are almost all for experts.

Re: Why ML/OCaml are good for writing compilers (1998)

#23

Post by ue_ »

nv-vn wrote: post #21
ue_ wrote: post #15

Earlier quoted context omitted.

I've heard the concurrency situation with OCaml isn't very good, though I know nothing about that. Weirdly, this kind of bias and the idea that it doesn't have as many libraries for my particular domain (web programming) has put me off it, as much as I'd like to use it. Using functional languages without Lisp-like macros will always be sort of weird to me, like I'm missing out on something.

Just to clarify, it's not concurrency that's the issue but parallelism. You can write nice concurrent code pretty easily, but writing code that runs on multiple cores is still a problem. Also, if you're interested in using OCaml for web programming, there is some pretty cool stuff you might wanna check out [1] [2] [3]. That said, there's no great solution to the lack of macros :/ [1] https://github.com/dannywillems/o…

Thanks for the links and info, I'll be looking into Ocaml more.

Re: Why ML/OCaml are good for writing compilers (1998)

#24

Post by rbehrends »

nv-vn wrote: post #21
ue_ wrote: post #15

Earlier quoted context omitted.

I've heard the concurrency situation with OCaml isn't very good, though I know nothing about that. Weirdly, this kind of bias and the idea that it doesn't have as many libraries for my particular domain (web programming) has put me off it, as much as I'd like to use it. Using functional languages without Lisp-like macros will always be sort of weird to me, like I'm missing out on something.

Just to clarify, it's not concurrency that's the issue but parallelism. You can write nice concurrent code pretty easily, but writing code that runs on multiple cores is still a problem. Also, if you're interested in using OCaml for web programming, there is some pretty cool stuff you might wanna check out [1] [2] [3]. That said, there's no great solution to the lack of macros :/ [1] https://github.com/dannywillems/o…

Strictly speaking, it's not parallelism, but multi-threaded code that operates on shared memory and which is not limited to arrays over scalars.

Re: Why ML/OCaml are good for writing compilers (1998)

#25

Post by adriancooney »

vmasto wrote: post #2

For anyone interested and isn't aware yet Facebook is developing Reason, a layer over OCaml. I've been fiddling with it for the past couple of weeks and coming from JavaScript I personally found the experience generally enjoyable. https://facebook.github.io/reason/

That was an extremely pleasant and convincing introduction, thank you for that. I'm definitely going to give this a try in future projects.

Re: Why ML/OCaml are good for writing compilers (1998)

#26

Post by lacampbell »

Dangeranger wrote: post #3

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis…

Ocaml is a great language. But the sad fact is I'm not going to be as productive in it as I would be in worse languages that have more libraries and tools.

Re: Why ML/OCaml are good for writing compilers (1998)

#27

Post by ms013 »

throwaway7645 wrote: post #5
Dangeranger wrote: post #3

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis…

Crappy windows support for OCaml. F# is similar to OCaml, but is very difficult for beginners and those not familiar with .NET. I also don't see a lot of beginner material for OCaml.

I've moved to doing ocaml development on my windows 10 machine under the windows subsystem for Linux. The Linux ocaml tool chain works pretty seamlessly there. Works very smoothly relative to past experiences with native ocaml compilers on windows.

Re: Why ML/OCaml are good for writing compilers (1998)

#28

Post by rbehrends »

I'll note that some of the aspects don't necessarily work out like that in practice:

1. The GC part is true, but one has to remember that this was written at a time when GC was still a bit of an unusual feature in mainstream languages.

2. Tail recursion doesn't really make much of a difference for walking trees, which is recursive, but (mostly) not tail recursive.

3. OCaml in particular uses 63/31-bit ints due to implementation details, which isn't a good fit for 64/32-bit integers. The strings and bignum part is mostly right, though.

4. ADTs can be good or bad for describing ASTs. Once you enrich ASTs with semantics shared by all variants (such as source coordinates), inheritance can become a better fit than ADTs.

8. Type inference doesn't really extend to module signatures, which you have to write out explicitly (though tooling such as `ocamlc -i` allows you to let the compiler help you write them). I also generally find it better to explicitly annotate functions with types. Not only does it make the code more readable later in its life, but you get fewer truly impenetrable type error messages because you forgot parentheses or a semicolon somewhere.

That said, there are several good points still.

Re: Why ML/OCaml are good for writing compilers (1998)

#29

Post by coolsunglasses »

rbehrends wrote: post #28

I'll note that some of the aspects don't necessarily work out like that in practice: 1. The GC part is true, but one has to remember that this was written at a time when GC was still a bit of an unusual feature in mainstream languages. 2. Tail recursion doesn't really make much of a difference for walking trees, which is recursive, but (mostly) not tail recursive. 3. OCaml in particular uses 63/31-bit ints due to imp…

>2. Tail recursion doesn't really make much of a difference for walking trees, which is recursive, but (mostly) not tail recursive.

Non-strictness helps here more than TCO in a strict language.

>4. ADTs can be good or bad for describing ASTs. Once you enrich ASTs with semantics shared by all variants (such as source coordinates), inheritance can become a better fit than ADTs.

Since this article was written we have better ways of augmenting/annotating ASTs. There's a lot of this out there, but here's one example: https://brianmckenna.org/blog/type_annotation_cofree

There are other alternatives that are like inheritance but with better reasoning properties as well. Finally tagless comes to mind.

>I also generally find it better to explicitly annotate functions with types.

This Haskeller whole-heartedly agrees for all the reasons stated.

Re: Why ML/OCaml are good for writing compilers (1998)

#30

Post by hongbo_zhang »

For web developers who are looking for an industrial strength functional language instead of JS, OCaml probably has the best story here.

Actually it has two OCaml->JS compilers of very high quality The first one, js_of_ocaml, could bootstrap the whole compiler several years ago(probably the first one there).

The recent one, https://github.com/bloomberg/bucklescript, push the JS compilation into next level, it generates fairly readable code, good FFI story, and its compilation is extremely fast, check out the compiler in JS version(http://bloomberg.github.io/bucklescript/js-demo/), and imagine how fast it would be for the compiler in native version. BuckleScript has a good story for Windows, and generates fairly efficient code, see benchmark here: https://github.com/neonsquare/bucklescript-benchmark BuckleScript is already used in production by big companies: for example Facebook messenger.com 25% is powered by BuckleScript, the new WebAssembly spec interpreter by Google is also partly cross compiled into JS by BuckleScript.

Disclaimer: I am one of the authors of BuckleScript

Post reply on HN