[Haskell-cafe] Byte Histogram

[Richard O'Keefe]

On 4/02/2011, at 10:10 AM, Andrew Coppin wrote:
> 
> The important obsevation is this: One tiny, almost insignificant change can transform a program from taking 50 seconds and 400 MB of RAM into one that takes 0.02 seconds and 0.1 MB of RAM. And, at least in this case, the simpler version is the slow one.
> 
> To say that Haskell is "slow" is both a little bit vague, and not really backed up by facts. In about 5 minutes flat, I managed to write a Haskell program that's very simple, and yet faster than a comparably simple C++ program (and C++ is supposed to be "fast"). So it's not that Haskell is "slow". It's that Haskell is *tricky*. Tiny, tiny little changes that look innocuous can have vast effects on performance. And this is a nice little example of that effect.

This seems to me to be the heart of the message, so maybe this reply is on-topic.

Back in the days when systems other than Wintel and maybe sort of intel Linux were
supported by Clean, I used to really love one of the features of the Clean compiler.
One simple command line switch and the compiler would list the names of all your
top level functions together with their types, and the types included strictness.
(Also uniqueness, not relevant to Haskell.)

The GHC documentation says the information is in the interface files,
but they are binary now, and I can't find it there.

> That got me thinking... What would happen if, instead of "Integer", we had two types, "evaluated Integer" and "possibly unevaluated Integer"? What if the strictness or otherwise of a data structure were exposed at the type level?

Oh, you mean like "!Int" and "Int" in Clean?  I used to find bang *types* rather easier to deal with
than I now do bang *patterns*.

> Currently, if you want a strict list, you have to implement one yourself. But is that strict in the spine, or the elements, or what?

Spine strict: ![t].
Spine and element strict: ![!t].
> 
> I have no idea what the syntax for that would look like,

Clean?