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

131–140 of 151 posts

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

#131

Post by sgrove »

ernst_klim wrote: post #129
eru wrote: post #127

Earlier quoted context omitted.

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?

I think by "argumentless function" OP just means "a function taking a single, unnamed argument", which is what function does as opposed to fun in OCaml (As you say, function is just sugar for (fun arg -> match arg with .... ) - it's a common enough idiom to have some sugar in the syntax).

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

#132

Post by e12e »

cies wrote: post #124
e12e wrote: post #92

Earlier quoted context omitted.

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?

It's been a while - but pretty much what Reason address - although I'd prefer filling in SML for js-ish syntax.

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

#133

Post by lobster_johnson »

ernst_klim wrote: post #125
atombender wrote: post #115

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…

Sorry, I should have been clearer. As I'm aware you have the choice between several ways:

  let foo : unit -> unit = 

  let foo = function
    | 

  let foo = (function () -> )

  let foo = (fun () -> )
I'm not an expert, but I guess this awkwardness comes from OCaml not having a dedicated function-declaration syntax; so if you do:

  let foo = do_stuff + 42;
...then you're obviously just defining a variable, which is evaluated right away. Which means that the only way to define a "procedure"-type function that takes zero arguments is the above.

> What do you mean by "readline" support?

Readline is a library that adds a line editor to a REPL. It adds keyboard shortcuts (arrow keys etc.), history, autocompletion, and so on. Unlike almost every single REPL out there (Python, Ruby, Haskell, etc.), OCaml doesn't come with built-in support, as far as I've been able to determine. You have to run "rlwrap ocaml" to get Readline into your REPL.

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

#134

Post by dleslie »

cies wrote: post #123
dleslie wrote: post #105

Earlier quoted context omitted.

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?

I was some years ago, before I gave up on the language; but one shouldn't have to be fluent in a language for it to satisfy the concepts of self-documentation and readability.

Requiring domain-specific knowledge of symbolic notation is not a trait of self-documenting languages. Recommending that the API search engine be open alongside or within your editor is likewise not a trait of self-documenting languages.

Self-documenting languages are coherent at-a-glance to average programmers with little to no knowledge of the language. Haskell is not this.

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

#135

Post by rbehrends »

wtetzner wrote: post #116
rbehrends wrote: post #98

Earlier quoted context omitted.

First, inheritance provides a strict superset of standard ADT functionality. Proof: Scala does ADTs through inheritance. ADTs are basically isomorphic to a closed two-tiered inheritance hierarchy with an abstract superclass at the top tier. Second, you're confusing inheritance with the ability to map subtypes to operations (and in statically typed languages, in a type-safe fashion). This is a function of OCaml's (or…

> First, inheritance provides a strict superset of standard ADT functionality. That's not true. Much of the value of ADTs in OCaml is full type inference. Scala has type inference, but it only sorta-kinda sometimes works. In other words, a lot of the value of OCaml's types are that they are quite flexible, while still having enough restrictions for the compiler to usefully reason about them.

> That's not true. Much of the value of ADTs in OCaml is full type inference.

I consider using type inference for your interfaces to be a software engineering anti-pattern. (Scala also doesn't really support that, except for return types, but you see related issues if you try type inference with objects in OCaml.) Without explicitly typing your interface, users have to look at the implementation to know what the type of a function is. Type inference for local entities is usually pretty easy.

Most of the remaining problems with type inference in Scala are the result of prioritizing Java interoperability in the type system, leading to a number of contortions and workarounds.

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

#136

Post by noblethrasher »

rbehrends wrote: post #98
willtim wrote: post #76

Earlier quoted context omitted.

ADTs and pattern matching are much more convenient and higher-level in practice than using OOP with inheritance. The visitor pattern, essentially just a fold, is the best one can do in an OOP language. With type-class abstractions and data type generic programming, the gap widens further. In Haskell, my current FP language of choice, I can implement a complex transform such as Lambda lifting in a few 10's of lines of…

First, inheritance provides a strict superset of standard ADT functionality. Proof: Scala does ADTs through inheritance. ADTs are basically isomorphic to a closed two-tiered inheritance hierarchy with an abstract superclass at the top tier. Second, you're confusing inheritance with the ability to map subtypes to operations (and in statically typed languages, in a type-safe fashion). This is a function of OCaml's (or…

I'm happy that you posted this. It's something that I discovered on my own, and have been tentatively arguing for years[1][2][3][4].

In fact, I never really understood the visitor pattern until after I started using ML's pattern matching. The "eureka" moment came when I realized that not only do abstract classes map to sum types (logical disjunction), but interfaces correspond to product types (logical conjunction).

[1] https://www.reddit.com/r/programming/comments/2e572a/rebutta...

[2] https://www.reddit.com/r/programming/comments/14t3ay/either_...

[3] https://news.ycombinator.com/item?id=822479

[4] http://stackoverflow.com/questions/19696342/limiting-class-a...

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

#137

Post by hajile »

akhilcacharya wrote: post #4
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…

>After using it for a couple of weeks I am confused why ML/OCaml aren't more popular For me, the issue is the GIL, although that is being worked on as we speak.

CML/MLton or Manticore will deal with most of those issues.

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

#138

Post by wtetzner »

virtualwhys wrote: post #122
wtetzner wrote: post #113

Earlier quoted context omitted.

> 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.

That's what I thought, and why I was confused by the original comment. Scala.js doesn't seem to have any benefits over js_of_ocaml, unless you prefer the language itself.

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

#139

Post by wtetzner »

lobster_johnson wrote: post #133
ernst_klim wrote: post #125

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…

Sorry, I should have been clearer. As I'm aware you have the choice between several ways: let foo : unit -> unit = let foo = function | let foo = (function () -> ) let foo = (fun () -> ) I'm not an expert, but I guess this awkwardness comes from OCaml not having a dedicated function-declaration syntax; so if you do: let foo = do_stuff + 42; ...then you're obviously just defining a variable, which is evaluated right a…

You can also do this:

    let foo () =

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

#140

Post by lobster_johnson »

wtetzner wrote: post #139
lobster_johnson wrote: post #133

Earlier quoted context omitted.

Sorry, I should have been clearer. As I'm aware you have the choice between several ways: let foo : unit -> unit = let foo = function | let foo = (function () -> ) let foo = (fun () -> ) I'm not an expert, but I guess this awkwardness comes from OCaml not having a dedicated function-declaration syntax; so if you do: let foo = do_stuff + 42; ...then you're obviously just defining a variable, which is evaluated right a…

You can also do this: let foo () =

That's news to me. Thanks!
Post reply on HN