Live data from Hacker News

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

flint.cs.yale.edu

121–130 of 151 posts

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

#121

Earlier quoted context omitted.

OCaml from the Very Beginning is amazing beginner material.

Thanks, I'll take a look again. He has some sample chapters posted that look really short(3 pages), but I'm guessing that is just a chapter snippet as the book itself is 200 pages?

The book is short, but there are plenty of exercises and worked solutions in the back. Do the exercises and you will get your money's worth. I suggest buying it with the bundle because More OCaml is good also.

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

#122
post #85

Earlier quoted context omitted.

I'd be interested to learn how web-dev in OCaml->JS compares to web-dev with Scala.js. The latter has the amazing JVM eco-system to hand. (I'm not interested in a Scala vs Ocaml language comparison. I know both languages very well. I'd be interested in the quality of JS support.)

> The latter has the amazing JVM eco-system to hand. What do you mean? Scala.js allows you to use things from the Java ecosystem in JavaScript?

Only if it's been ported to Scala.js; in fact, same goes for Scala to Scala.js, all libs need to be cross compiled.

The only thing you get for "free" in Scala.js is Scala, which is of course no small accomplishment, but the JVM ecosystem as a whole does not come with it.

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

#123
post #82

Earlier quoted context omitted.

Wholly disagree. Yes in Haskell you can define operators yourself (they are just functions but made out of special characters and placed after the first argument, e.g.: "Hi " ++ username); and this is often done by Haskellists. So you sometimes need to learn a few new operators that come with a library to WRITE code using that lib; but in order to READ code I rarely need to ref the docs, it is just evident from the c…

shrug When I look at Haskell code I see overly terse expressions and nothing resembling the concept of self-documentation.

Are you fluent in Haskell?

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

#124
post #92

Earlier quoted context omitted.

I find OCaml's syntax simple and clear. I don't get the reason for Reason, but hope it leads to more OCaml adoption.

OCaml might be simple and clear, but starting from Standard ML - there's a number of differences that feel like warts and needless complications for no discernable gain for the programmer . I do think Reason fix up a few of these ancient and partially crumbled stone walls making the ocaml landscape easier to criss-cross for a new generation of programmers.

> there's a number of differences that feel like warts and needless complications for no discernable gain

Such as?

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

#125

Earlier quoted context omitted.

>I find OCaml's syntax to be quite gnarly What's wrong with the OCaml syntax? It's much more clean than say scala's one, it's indentation insensitive, and a' list feels more relevant than the list

It's a lot of little random things. For example, the ~keyword: syntax, the need to paranthesize where other languages don't (e.g.: "foo -1" doesn't work, you have to do "foo (-1)"). The way argumentless functions must be declared with "function". The expression termination issue (";;") is a lot less elegant than, say, Haskell's whitespace awareness. Operators not being overloaded is annoying, although there's a valid…

>The way argumentless functions must be declared with "function".

Could you show an example, I don't get it?

>The expression termination issue (";;")

Strange, I've never used ";;" in my code, only in repl.

>Operators not being overloaded is annoying, although there's a valid argument for explicitness.

Overloading is harmful. It's definitely the wrong way to do ad-hoc polymorphism, and OCaml have a polymorphic comparison operators, which brought so much headache. Type classes or modular implicits are the right way to do ad-hoc. Looking forward to see modular implicits in OCaml [1].

>For example, having a REPL without built-in readline support (rlwrap to the rescue)

What do you mean by "readline" support?

[1] http://ocamllabs.io/doc/implicits.html

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

#126

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…

I'm optimistic about Reason, Facebook's new syntax "skin" on top of OCaml. I find OCaml's syntax to be quite gnarly; of the MLs, F# is probably the cleanest and most modern-feeling. Something like F# without the .NET stuff could have been amazing.

F# has lots of .net warts. Haskell is probably the cleanest ML syntax-wise in somewhat widespread use.

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

#127

Earlier quoted context omitted.

It's a lot of little random things. For example, the ~keyword: syntax, the need to paranthesize where other languages don't (e.g.: "foo -1" doesn't work, you have to do "foo (-1)"). The way argumentless functions must be declared with "function". The expression termination issue (";;") is a lot less elegant than, say, Haskell's whitespace awareness. Operators not being overloaded is annoying, although there's a valid…

>The way argumentless functions must be declared with "function". Could you show an example, I don't get it? >The expression termination issue (";;") Strange, I've never used ";;" in my code, only in repl. >Operators not being overloaded is annoying, although there's a valid argument for explicitness. Overloading is harmful. It's definitely the wrong way to do ad-hoc polymorphism, and OCaml have a polymorphic compari…

OCaml doesn't have argumentless functions.. But they do have functions that take a 'unit' argument.

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

#128
post #104

Earlier quoted context omitted.

>I find OCaml's syntax to be quite gnarly What's wrong with the OCaml syntax? It's much more clean than say scala's one, it's indentation insensitive, and a' list feels more relevant than the list

One problem is that it is full of shift-reduce conflicts, due to a lack of an "end" token in most expressions. The one that bugs me the most is nested match expressions, which often need to be wrapped in parenthesis.

In OCaml's expression syntax, "begin" is a synonym for left parenthesis, and "end" is a synonym for right parenthesis. So I've taken to just using "begin match e with ... end" in every situation to avoid this problem.

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

#129
post #127

Earlier quoted context omitted.

>The way argumentless functions must be declared with "function". Could you show an example, I don't get it? >The expression termination issue (";;") Strange, I've never used ";;" in my code, only in repl. >Operators not being overloaded is annoying, although there's a valid argument for explicitness. Overloading is harmful. It's definitely the wrong way to do ad-hoc polymorphism, and OCaml have a polymorphic compari…

OCaml doesn't have argumentless functions.. But they do have functions that take a 'unit' argument.

I know, I've asked about this:

>The way argumentless functions must be declared with "function".

function is just a sugar for fun+match, what does it have to do with argumentlessness?

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

#130

Earlier quoted context omitted.

> 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. I've written plenty of OCaml, and I can't see how this would ever be a problem. Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. An why would pattern matching cause it? Maybe I'm misunderstand…

I've done it when writing translators / compilers for school. If you're pattern matching against an AST, its easy to to have a pretty big list of possible types the AST can contain. Probably this is a code smell that should be rearchitected.

Haven't used OCaml but the recommended practice in Erlang/Elixir is to break down complex pattern matches into separate function clauses, as function calls are also driven by pattern matching.
Post reply on HN