
Haskell Primitives - LukeHoersten
https://www.fpcomplete.com/blog/2015/02/primitive-haskell
======
LukeHoersten
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"

~~~
tome
I never understood why these weren't

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

or something else at least somewhat meaningful.

~~~
pash
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...](http://stackoverflow.com/questions/15893524/what-is-the-meaning-of-
let-x-x-in-x-and-data-float-in-ghc-prim-in-haskell)

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

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

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

------
jpt4
"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).

------
wyager
Cool article! Very in-depth.

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

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

------
FullyFunctional
Why this intentional misleading title?

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

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

