Haskell Primitives | Hacker News Reader

Haskell Primitives

fpcomplete.com

72 pointsLukeHoersten15 comments

SPJ, co-author of GHC, added this awesome comment:

""Look at the implementation of other functions in GHC.Prim;they're all defined as let x = x in x."

This begs the question of why this strange code exists at all. Answer: the sole reason is to give Haddock documentation for the primops a place to live. GHC.Prim is processed by Haddock more or less like any other module; but is effectively ignored by GHC itself.

Worth saying this.

Simon"

I never understood why these weren't

    primop = let x = x in x
    (+#) = primop

or something else at least somewhat meaningful.

I don't know the answer to that, but I suspect it might be because there is some reason for the code in GHC.Prim to be monomorphic.

There is a Stack Overflow discussion about this that gives a bit more background, by the way. (The answer needlessly digressing into the lambda calculus is mine.)

0. http://stackoverflow.com/questions/15893524/what-is-the-mean...

This is one of my favorite innards-of-Haskell articles. It's such an intuitive way to look at how a super high level language like Haskell gets down to machine primitives. So important for optimization too.

I've been in HFT for a while and what strikes me is the performance optimizations you make in C++, Java, and Haskell are actually so so similar. Get down to the primitives. Avoid boxing. Avoid memory allocation at run time. Makes me think any language can be performant if you know what you're doing.

Exactly. And optimized Haskell doesn't quite look to "that beautiful FP language" anymore, but becomes more imperative.

I was thinking more stream fusion and rewrite rules etc. GHC is a lot more powerful in that sense than the other language compilers I mentioned. A lot of it in Haskell just boils down to bang patterns on data types. And where it does get messy as you suggest (yeah it does), you can nicely abstract it away behind a pure library interface. That way the mess is encapsulated.

You know how people use Python for most of their code and write c bindings for performance intensive parts?

Idiomatic Haskell for most of my code and imperative Haskell for performance achieves something similar without having to switch languages.

If you really need C, Haskell also makes it pretty easy as well.

Is this where someone points out the more functional intermediate SSA that imperative languages often get translated into at some point during the compilation?

"When GHC reaches a call to one of these primops, it automatically replaces it with the real implementation for you, which will be some assembly code, LLVM code, or something similar."

This, plus the "magic hashes" reminds me a great deal of Urbit's hinting syntax for jet propulsion (associating a body of high-level code in Hoon with an alternative (presumably low-level) implementation).

Cool article! Very in-depth.

Since Haskell is lazy, how does packaging io into a chain of function calls guarantee ordering? Does it depend on some primitives being strict?

There's an internal representation which ensure than IO actions are evaluated in the correct order.

Why this intentional misleading title?

What's misleading? It's an article about primitive operations and types in GHC Haskell.

The actual title is "Primitive Haskell" which certainly confused me when I first saw it (some weeks ago).

Reply on news.ycombinator.com