Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell Primitives

fpcomplete.com

Post reply on HN
Print view View original

1–10 of 17 posts

Re: Haskell Primitives

#3

Post by 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.

Re: Haskell Primitives

#5

Post by 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"

Re: Haskell Primitives

#8

Post by tome »

LukeHoersten wrote: post #5

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…

I never understood why these weren't

    primop = let x = x in x
    (+#) = primop
or something else at least somewhat meaningful.

Re: Haskell Primitives

#9

Post by pash »

tome wrote: post #8
LukeHoersten wrote: post #5

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…

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

Re: Haskell Primitives

#10

Post by zura »

LukeHoersten wrote: post #3

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…

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