Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

If you take a look at how the GHC Haskell compiler (A "Sufficiently Smart Compiler(tm)" in my opinion) works, for example, it is not naively pushing allocating objects, creating thunks and emitting trampoline code.

Instead, it analyzes the program structures from graphs and emits rather efficient machine code in the end. Not too dissimilar from what your native code emitting C compiler does.

If you look at the machine code for something as "stupid" as the Haskell example below, the output object code does not resemble the semantics of the source program at all. (it's not quite as efficient as the same from a C compiler, but still proves a point)

    foreign export ccall fac :: Int -> Int
    fac :: Int -> Int
    fac n = foldl (*) 1 . take n $ [1..]

Compiler and programming language research is a very important topic that yields real performance benefits as well as better programmer productivity. That includes using Category theory to reason about program correctness.

If you're interested in how the Haskell compiler works, "Implementation of Functional Programming languages" is a good (albeit a bit outdated) starting point. The whole book is freely available here: http://research.microsoft.com/en-us/um/people/simonpj/papers...

I do agree with the title a bit, though. Some of our computer programming environments are just ridiculously slow. Being slow also means "consumes a lot of power" which is important when more and more computers are powered by batteries.

The OP (which I totally agree with!) also states:

> Such a compiler could properly determine that intermediate steps are unused, merge them (e.g. translate x.map(f).map(g) to x.map(x => g(f(x))))

Ironically, GHC does that already[0], and will also do TCO.

[0] http://metagraph.org/papers/stream_fusion.pdf

Correct me if I'm wrong, but teaching a computer to produce good low level code from high level code seems very similar to the machine translation problem (translating English to X). Why are people so hopeful about solving the former problem when the latter problem is so hard? Or are these two problems so different that the failure so far to solve one has no impact on the other?

I'd say those two things are only superficially similar. One is trying to correctly interpret a syntax which

- is tailored to the characteristics of extremely parallel computers which spend years unconsciously learning somewhat pointless statistical micro-rules, and then layer a formal grammar on top of that (both layers need to be correctly maintained); and

- sometimes, due to ambiguity, can't be parsed without understanding the nature of what is being referred to (which can be anything one can imagine).

The other is trying to transform expressions which are already formally specified (with semantics to a large extent based on computers' whims rather than humans', even in very high-level languages) into a more efficient form. Doing this as well as humans can could require AI-ish "reasoning" about parts of the program, but it's basically a different task. There's no need to understand everything in the world to know what a Haskell program does.

Even a high-level programming language has a strict grammar with no ambiguity, albeit maybe with some syntactic sugar and "higher-level" atoms. The same cannot be said about natural languages.

Designing a mapping from a new language to machine code is easier than retroactively trying to map two languages together that were never meant to be. Especially if those languages are complex and ill-defined.

Seconding on the SPJ book! It's a solid start for learning about the particulars of FP implementation.

The complaints in the article don't really generalize at all. It seems to just be a rant about why targeting the JVM from a functional language can yield non optimal code without certain program transformations. Haskell and OCaml don't have the problems mentioned here at all. I wish the title actually reflected the content rather than just being kind of antagonistic about functional programming.

For anyone curious, here is the dissasembly of the above code:

http://pastebin.com/R3QiCBsK

And the entire resulting object file:

http://pastebin.com/a21pqaKW

What do all the call statements do? They seem a little redundant as they skip forward to the next statement each time.

Note that the operand in each case is 0x00000000.

I suspect this is a disassembly of the .o file, or maybe it's some runtime dynamic linking thing? There'll be a fixup table somewhere and this stuff will be sorted out before it's executed.

The Glasgow Haskell Compiler Haskell Compiler? Never heard of that one :P

Reply on news.ycombinator.com