is Haskell a managed language?

13
votes

I'm a complete newbie in Haskell. One thing that always bugs me is the ambiguity in whether Haskell is a managed(term borrowed from MS) language like Java or a compile-to-native code like C?

The GHC page says this "GHC compiles Haskell code either directly to native code or using LLVM as a back-end".

In the case of "compiled to native code", how can features like garbage collection be possible without something like a JVM?

/Update/

Thanks so much for your answer. Conceptually, can you please help point out which one of my following understandings of garbage collection in Haskell is correct:

GHC compiles Haskell code to native code. In the processing of compiling, garbage collection routines will be added to the original program code?

OR

There is a program that runs along side a Haskell program to perform garbage collection?

5
haskellghc
Why would you need a VM for garbage collection? - sepp2k
When Microsoft says "Managed", I'm pretty sure they are referring not to Java, but to CLI-hosted languages, as distinct from "native code". - Arafangion
Not to beat the dead horse, but you can garbage collect C code (PDF). - Thomas M. DuBuisson
There are a couple problems. Almost any language can be either byte-compiled or compiled to native code, C# can be compiled to native code if you like. And plain old C can be interpreted (there exist C interpreters! wacky!). So it has nothing to do with the language itself, it is all about implementations. It is kind of like asking whether English is a native language -- some people are native English speakers and some people learned English as a foreign language. It has nothing to do with English itself. - Dietrich Epp
@TommyQ: look at it this way: if a programmer has as much control over the exact native code that is produced, then making a good GC is hard (but not impossible, as it has been demonstrated). With GHC you (probably) have much less control about the exact native code that is generated, so the compiler is free to add whatever tricks it needs to implement a good GC without a virtual machine. The difference is simply that in a .NET application the GC lives in the runtime and the VM, while in the compiled Haskell code it lives in the runtim and the compiled code. - Joachim Sauer

5 Answers

21
votes

As far as I am aware the term "managed language" specifically means a language that targets .NET/the Common Language Runtime. So no, Haskell is not a managed language and neither is Java.

Regarding what Haskell is compiled to: As the documentation you quoted says, GHC compiles Haskell to native code. It can do so by either directly emitting native code or by first emitting LLVM code and then letting LLVM compile that to native code. Either way the end result of running GHC is a native executable.

Besides GHC there are also other implementations of Haskell - most notably Hugs, which is a pure interpreter that never produces an executable (native or otherwise).

how can features like garbage collection be possible without something like a JVM?

The same way that they're possible with the JVM: Every time memory is allocated, it is registered with the garbage collector. Then from time to time the garbage collector runs, following the steps of the given garbage collection algorithm. GHC-compiled code uses generational garbage collection.

In response to your edit:

GHC compiles Haskell code to native code. In the processing of compiling, garbage collection routines will be added to the original program code?

Basically. Except that saying "garbage collection routines will be added to the original program code" might paint the wrong picture. The GC routines are just part of the library that every Haskell program is linked against. The compiled code simply contains calls to those routines at the appropriate places.

Basically all there is to it is to call the GC's alloc function every time you would otherwise call malloc.

Just look at any GC library for C and how it's used: All you need to do is to #include the library's header and link against the library, and replace each occurence of malloc with the GC library's alloc function (and remove all calls to free) and bam, your code is garbage collected.

There is a program that runs along side a Haskell program to perform garbage collection?

No.

13
votes

whether Haskell is a managed(term borrowed from MS) language like Java

GHC-compiled programs include a garbage collector. (As far as I know, all implementations of Haskell include garbage collection, but this is not part of the specification.)

or a compile-to-native code like C?

GHC-compiled programs are compiled to native code. Hugs interprets programs, and does not compile to native code. There are several other implementations which all, as far as I know, compile to native code, but I list these separately because I'm not as confident of this fact.

In the case of "compiled to native code", how can features like garbage collection be possible without something like a JVM?

GHC-compiled programs include a runtime system that provides some basic capabilities like M-to-N green threading, garbage collection, and an IO manager. In a sense, this is a bit like having "something like a JVM" in that it provides many of the same features, but it's very different in implementation: there is no common bytecode across all architectures (and hence no "virtual machine").

which one of my following understandings of garbage collection in Haskell is correct:

  1. GHC compiles Haskell code to native code. In the processing of compiling, garbage collection routines will be added to the original program code?
  2. There is a program that runs along side a Haskell program to perform garbage collection?

Case 1 is correct: the runtime system code is added to the program code during compilation.

4
votes

"Managed language" is an overloaded term so here are one-word answers and then some details for the usual different meanings that come to (my) mind:

Managed as in a CLR target

No, Haskell does not compile to Microsoft CLI's IL.
Well, I read there are some solutions that can do that, but imo, don't.. the CLR isn't built for FP and will seriously lack optimizations, probably yielding a research language performance. If I personally would really really want to target the CLR, I'd use F# -- it's not a functional language but it's close.

N.B. This is the most accurate and actual meaning for the term "managed language". The next meanings are, well, wrong, but nevertheless & unfortunately common.

Managed as in automatically garbage-collected

Yes, and this is pretty much a must have. I mean, beyond the specification: If we would have to garbage collect it would destroy the functional theme that makes us work in the high altitudes that are our beloved home.

It would also enforce impurity and a memory model.

Managed as in compiled to bytecode which is ran by a VM

No (usually).
It depends on your backend: Not only we have different Haskell compilers today, some compilers have different backends -- there are even backends for JavaScript!

So if you do want to target a VM, you can use an existing / make a backend for it. But Haskell doesn't require it. So just as you can compile to native raw-metal binary, you can compile to anything else.

In contrast to CLR languages like C#1, VB.NET, and in contrast to Java, etc. you don't have to target a JVM, the CLR, Mono, etc. as Haskell doesn't require a VM at all.

GHC is a good example. When you compile in GHC, it doesn't compile you straight to binary, it compiles to an intermediate language called Core, and then optimizes from Core to Core for some times before it proceeds to another language called STG, and only then proceeds to code generation (it can stop there if you tell it to).2 And these days you can also use it to compile to LLVM bytecode (which is subject to some awesome optimizations). With the LLVM backend, GHC can produce wildly faster programs. For more information about it and about GHC backends, go here.

The diagram below illustrates the GHC compilation pipeline, and here you can find more information about the various stages.

The GHC compilation pipeline

See the fork at the bottom for three different targets? those are the backends I was referring to.

1 A future exception and a fun fact: Microsoft are currently working on native .NET! the cunningly named: Microsoft .NET Native.

1
votes

What, for you, is the defining feature of a "managed language"? The phrase "GHC compiles Haskell code either directly to native code or using LLVM as a back-end" that you quote is quite clear about what GHC does, so I suspect the "ambiguity" that bugs you is rather in the term "managed language" than in GHC's docs.

In the case of "compiled to native code", how can features like garbage collection be possible without something like a JVM?

How exactly do you think "something like a JVM" implements features like garbage collection? The JVM isn't magic, it's just a program like everything else. At some level you need to have native code in order for the CPU to execute it, so clearly features like garbage collection are possible in native code.

0
votes

For where you currently are, it's probably best to think of (GHC) Haskell as "managed," but that the platform GHC compiles to is not targeted by anything else. There is, of course, more to it than that, but that's a sufficient explanation in lieu of more Haskell experience.