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

111–120 of 151 posts

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

#111

Post by macintux »

59nadir wrote: post #73
nv-vn wrote: post #17

Earlier quoted context omitted.

Sadly, I'm starting to lose my hope over multicore. It's been in the works for as long as I've used the language with much speculation of it being "almost done" or "in the next release" that have failed to materialize. That said, I don't have the time to really follow along with the compiler's development so take that with a grain of salt.

Precisely this is the reason I've lost hope with regards to OCaml as a main language. Multicore, specifically, is one of those things that has been "close" for so long that it's looking like a Duke Nuke'em Forever feature. I keep track of OCaml regularly because I love the language and I find that it's probably the best combination of features in one place, both in terms of my enjoyment as a programmer and in terms o…

Good news, there is indeed Alpaca: ML for the BEAM.

https://github.com/alpaca-lang/alpaca

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

#112

Post by rbehrends »

Symmetry wrote: post #108
rbehrends wrote: post #24

Earlier quoted context omitted.

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

You're talking about data parallelism, the OP is talking about task parallelism. Since in both cases things are occurring in parallel it makes sense to use 'parallelism' as an umbrella term for both and it was clear from context here that it was task parallelism under discussion.

I am talking about both. You can have task parallelism in a distributed system with no shared memory, after all.

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

#113

Post by wtetzner »

mafribe wrote: post #85
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…

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?

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

#114

Post by wtetzner »

scythe wrote: post #61
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 t…

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

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

#115

Post by atombender »

ernst_klim wrote: post #99
atombender wrote: post #40

Earlier quoted context omitted.

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.

>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 argument for explicitness.

Overall, it's not a terrible syntax, but it feels a lot like someone just invented things along the way as they needed them, without a cohesive plan. Lots of pragmatic but visually ugly choices.

I also take issue with the tooling; things like error messages, or just the antiquated feel of the CLI tools. For example, having a REPL without built-in readline support (rlwrap to the rescue) in this day and age is not acceptable.

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

#116

Post by wtetzner »

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…

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

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

#117

Post by name_for_now »

continuational wrote: post #89
cies wrote: 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…

I'll just leave [Control.Lens.Operators]( http://hackage.haskell.org/package/lens-4.15.1/docs/Control-... ) here... In defense of Haskell, the situation is similar in Scala. I think some people just prefer inventing their own operators instead of using descriptive names.

To be fair, a number of those operators are

> This is an infix alias for cons. > This is an infix alias for snoc. > A convenient infix (flipped) version of toListOf. > An infix version of itoListOf.

And a lot of them are (<+~) and friends.

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

#118

Post by andrewvijay »

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…

Complete noob here. Bucklescript compiles ocaml to JavaScript? Or is it a new language by itself written in ocaml?

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

#119

Post by jldugger »

ihodes wrote: post #47
akhilcacharya wrote: post #4

Earlier quoted context omitted.

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

What does the lack of multi core keep you from doing?

In web-apps architectures, you have a choice: multithread or multiprocess. Multithreading is far more memory friendly, and occasionally a bit faster, but many interpreted language runtimes aren't prepared for multithreading. Python / OCaml have a big global lock on certain things (interpreter, garbage collection) that are needed frequently enough that even requests aren't really interfering at the DB transactional level will block one another under multithreading. So instead you have to take the hit of multiprocessing, where each web worker has its own memory space and set of locks.

So if you're going to justify writing a webapp in OCaml, it would be helpful if the language was more efficient than whatever your alternative is.

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

#120

Post by jldugger »

wtetzner wrote: post #114
scythe wrote: post #61

Earlier quoted context omitted.

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

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

Post reply on HN