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

141–150 of 151 posts

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

#141

Post by naasking »

rbehrends wrote: post #106
naasking wrote: post #102

Earlier quoted context omitted.

Sure, but not many real programs actually need the full 64-bits. Many of the ones that may seem to require the full bit width are doing bit ops on larger bit streams, for which there's ocaml-bitstream. What sort of programs are you thinking of?

Umm, compilers? That's what the post was about. Compilers need to be able to represent integer literals up to machine precision.

Compilers for languages with full-width integers need to represent full-width integer literals while compiling, sure. I'm not sure that it's:

a) all that common to need full width integers while compiling even these languages, and

b) all that problematic to use boxed numbers in this context, or big_int.

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

#143

Post by ernst_klim »

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…

>Readline is a library that adds a line editor to a REPL.

There is a great advanced REPL for OCaml if you need something beyond simple stuff:

https://github.com/diml/utop

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

#144

Post by rbehrends »

naasking wrote: post #141
rbehrends wrote: post #106

Earlier quoted context omitted.

Umm, compilers? That's what the post was about. Compilers need to be able to represent integer literals up to machine precision.

Compilers for languages with full-width integers need to represent full-width integer literals while compiling, sure. I'm not sure that it's: a) all that common to need full width integers while compiling even these languages, and b) all that problematic to use boxed numbers in this context, or big_int.

What you are saying here is that it isn't a huge problem in practice, and I agree with that. However, that's not what the original post was saying. It said that OCaml was especially suited for writing compilers because of its ints, which is the exact opposite claim.

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

#145

Post by mafribe »

wtetzner wrote: post #138
virtualwhys wrote: post #122

Earlier quoted context omitted.

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.

I was expressing myself sloppily, sorry. You still can use many things in the JVM ecosystem because you can compile (most of) scala.js not only to Javascript but also to the JVM, and then analyse the code with JVM specific tools like fuzzers, debuggers, profilers etc. This is powerful. Making sure your code runs on two platform will expose additional problems that one platform alone doesn't do.

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

#146

Post by klibertp »

jldugger wrote: post #119
ihodes wrote: post #47

Earlier quoted context omitted.

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

> In web-apps architectures, you have a choice: multithread or multiprocess.

No, the choice is definitely not that limited. Saying something like this is like saying there's no Nginx, only Apache available as an HTTP server. For the concurrent, IO-bound code you can leverage all kinds of concurrency approaches (coroutines, green threads, callbacks). In these use cases, multiple threads are actually a bad idea from the memory efficiency perspective.

On the other hand, multiple threads would be viable for CPU-bound and/or long-running code were it not for the GIL, that's true. With the GIL you don't have that option and have to resort to multiprocessing.

Multiprocessing is not so bad, actually, although it does make the code more complicated. Unless your problem is massively parallel (but then you'd use GPU instead), spawning n x 2 processes for n cores is definitely possible with how much RAM is available nowadays on the servers. You get optimal parallelism at the cost of serialization overhead (or other complexities if you want to directly share memory).

There are some languages which do support most existing concurrency mechanisms and they may be a better fit for a particular project. However, not supporting parallelism via multi-threading hardly disqualifies any language, provided the other tools are in place, solid and widely used.

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

#147

Post by twoquestions »

cies wrote: post #78
jasim wrote: post #68

Earlier quoted context omitted.

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!

I can testify that the the Discord channels are a very welcoming place.

I can also verify this. The documentation is not perfect, and the fine people who hang out on Discord were able to lead me on how to fix the docs, and get me up and running.

Also, having full Intellisense for a JavaScript like language is amazing! I found it better for Reason than Typesript, oddly enough even in VS Code.

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

#148

Post by scythe »

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…

> Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml.

Me, no; my colleagues, yes. I am averse to writing long functions even more than most people. I agree with 'jldugger that this is a sign that some cleanup is needed but the point is that bad code exists in cool languages too (there are also Mondays in Australia).

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

#149

Post by ms013 »

throwaway7645 wrote: post #93
ms013 wrote: post #90

Earlier quoted context omitted.

I assume you were just not interested in passing the state around to the functions that needed it, and preferred the fact that the state monad hides that plumbing for you via bind and return. It's worth noting that there exist Ocaml libraries that provide the same operators and even similar do notation syntax that desugars to bind/return operators (via PPX). Ocaml does tend to be more verbose than Haskell - it's just…

Thanks for the thorough reply and it sounds like you're quite experienced here. Any chance going into more detail with what you do for a living? Do you maintain a compiler for something more mainstream?

I cofounded a company recently that is using code transformation and optimization methods to accelerate data analytics code on special purpose hardware. Our compilation toolchain is all ocaml, and the language that is compiled/transformed/optimized is Python. Prior to this venture, I did similar work - code analysis and transformation, but in that case largely around high performance computing for scientific applications. That tooling was mostly ocaml/Haskell, but not production focused - it was mostly research code.

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

#150

Post by wtetzner »

rbehrends wrote: post #135
wtetzner wrote: post #116

Earlier quoted context omitted.

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

I don't necessarily disagree with what you've said, my main point was that much of the value of ADTs in OCaml is in their restrictions.
Post reply on HN