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

61–70 of 151 posts

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

#61

Post by scythe »

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…

Like C++ and Perl, there's a bit of caution required to avoid writing unreadable OCaml code. A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later. IDE support for obscure languages is also often weak or requires extensions or idiosyncratic IDEs which are unfamiliar to many people (and often you want some kind of tool to collapse a 500-line function). OCaml has good vim plugins but not everyone uses vim.

That's my experience with it anyway.

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

#62

Post by sitkack »

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…

Because of package manager and library issues. Things aren't popular because of their inherent qualities or flaws. Popularity is driven by itself and external factors.

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

#63

Post by nv-vn »

hyperpallium wrote: post #50

How are simple parsers written in ML (or ocaml)? You can't use the coding style used for recursive descent in the Dragon compiler book, without using mutable variables. Do you have to use parser combinators, which have their own limitations?

The most common way is using a parser generator (ocamlyacc or menhir, both are basically interchangeable 99% of the time). Parser combinators are a choice, but honestly I think recursive descent parsers are more common than combinators in OCaml.

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

#64

Post by tpetricek »

hongbo_zhang wrote: post #59
tpetricek wrote: post #57

Earlier quoted context omitted.

I can confirm that the story of F# on the JS ecosystem is already quite good and is getting better every day. As already mentioned, Fable ( http://fable.io ) is the way to go today. I did two things that involve "writing compilers" using F# that target the web and did not have any notable issuues. - My coeffects page ( http://tomasp.net/coeffects ) is an implementation of a simple ML-like language with coeffect type…

Indeed, fable is a very neat project, but to be honest, it is not as mature as BuckleScript at this time. For example, it takes around 20~80ms to compile a single file for BuckleScript, while Fable would talk 10x more to compile. Its generated code is pretty but its performance is not very good, see this issue ( https://github.com/fable-compiler/Fable/issues/646 ) "this can make a difference in speed of up to about s…

I absolutely agree that the JS platform is large enough to have both!

That said, I think doing a fair comparison is going to be difficult. Although OCaml and F# share the same background, I think the OCaml and F# communities care about quite different things - and this can be seen in the difference between BuckleScript and Fable. OCaml compiler is very fast and produces efficient code and so it feels reasonable to expect the same for BuckleScript. F# is often slower, but people tend to care a lot about making interop nice. You can see this with the React bindings and Elmish tooling.

Those different goals are exactly the reason why there is room for both. I think Fable vs. BuckleScript mirror the philosophy of F# vs. OCaml with respect to .NET and native.

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

#65

Post by pka »

dleslie wrote: post #11
nv-vn wrote: post #6

The problem with this article is that it's missing an answer to why one would choose ML/OCaml over Haskell. Haskell has many more features, a more advanced type system, arguably superior syntax, and much better library support. However, I believe that OCaml/SML are often a better choice for a number of reasons. First of all, OCaml/SML are the best choice in terms of example code for compilers. They're historically th…

Also, Haskell is something of a soup of DSL-operators that require one spend significant time researching what they mean and what behaviour they induce. Even with such knowledge, it suffers from the Perl-ish woe of write-once and read-never.

https://www.haskell.org/hoogle :)

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

#66

Post by gsg »

rbehrends wrote: post #37
naasking wrote: post #35

Earlier quoted context omitted.

> 3. OCaml in particular uses 63/31-bit ints due to implementation details, which isn't a good fit for 64/32-bit integers I'm not sure what "isn't a good fit" is supposed to mean.

Try storing an integer literal that requires 64 bits in a variable that can hold only 63 bits. It's not going to make it impossible (you may just need something like a ShortIntLiteral and a LongIntLiteral variant), but it's going to require additional effort.

Use Int64.t?

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

#67

Post by tathougies »

throwaway7645 wrote: post #32
nv-vn wrote: post #6

The problem with this article is that it's missing an answer to why one would choose ML/OCaml over Haskell. Haskell has many more features, a more advanced type system, arguably superior syntax, and much better library support. However, I believe that OCaml/SML are often a better choice for a number of reasons. First of all, OCaml/SML are the best choice in terms of example code for compilers. They're historically th…

Haskell may indeed be one of the most advanced languages out there in terms of raw power, but it is very complex (how many monad tutorials does it seriously take to teach one of the most core pieces of the language) and how much category theory do you need to know to be moderately effective? Also, the ecosystem could use some work. An example is the main string library isn't used in favor of a different one. Using th…

Honestly, none. I'm not a category theorist, and have no more understanding of monads than anyone who's used a javascript promise library, and I've been employeed professionally as a Haskell programmer for the past year, contributed libraries back to the community, and given talks in my local area.

Haskell is a language like any other. Many people would like to complicate it, but if you spend the time learning its syntax and semantics, there is very little need to learn the theory.

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

#68

Post by jasim »

hongbo_zhang wrote: post #30

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 genera…

And the OCaml-as-JS community is small and very welcoming. How often can you get first-class support from the compiler makers as a newbie? Hongbo Zhang and Jordan Walke and Cheng Lou are all on the Discord channel and are extremely helpful.

Jump in fellas, the language is powerful, and the community is nice!

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

#69

Post by rbehrends »

gsg wrote: post #66
rbehrends wrote: post #37

Earlier quoted context omitted.

Try storing an integer literal that requires 64 bits in a variable that can hold only 63 bits. It's not going to make it impossible (you may just need something like a ShortIntLiteral and a LongIntLiteral variant), but it's going to require additional effort.

Use Int64.t?

1. This wasn't what the original article was talking about.

2. int64's are normally boxed.

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

#70

Post by nikofeyn »

hongbo_zhang wrote: post #30

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 genera…

better than clojure and f#?
Post reply on HN