[Haskell-cafe] Number 1, at least for now

[Donald Bruce Stewart]

Ben.Lippmeier:
> Donald Bruce Stewart wrote:
> 
> >>Ha! I don't think "pure lazy fp" would be the phrase I would choose to 
> >>describe this code.
> >>
> >>An example (from fannkuch):
> >>
> >>t <- IO $ \s ->
> >>    case readIntOffAddr# p1# 0# s of
> >>      (# s, p1 #) -> case readIntOffAddr# p1# (n# -# 1#) s of
> >>          (# s, pn #) -> (# s, not (p1 ==# 0# || pn ==# (n# -# 1#)) #)
> >
> >Ok, I'll bite ;) This is a very atypical "example", as fannkuch is the
> >only entry written this way (and it could be rewritten, with careful
> > attention to the Core). There are also many lovely pure, lazy entries.
> 
> Not so atypical.
> 
> More examples (I didn't look /that/ hard.. :))
> 
> -----------------------------------
> * From reverse-complement
> * From k-nucleotide.
> * From n-body.

Yeah, these were the hard entries to improve, and we tended towards
brute force. The problems were either IO intensive, or requiring mutable
state by spec definition, so we end up with tightly optimised inner loops,
and this is how we do that in Haskell :) 

Still, the majority of code is not written this way -- problems not
doing a lot of IO, or needing mutable arrays, are written at a higher
level.

The plan is that most of these ugly entries disappear once packed
strings are in the base library, which solves the IO issue. A good
packed string regex library would also be useful.

> *I* am certainly not implying that Haskell is anything less than the 
> most wonderous language in the entire world.
> 
> I'm saying that there's a stark difference in style between the programs 
> submitted to the shootout, and the ones I would show to people that I 
> myself was trying to introduce to the wonders of purely lazy functional 
> programming. :).

Hehe, Maybe I should write "Learning Haskell: The Shootout Way" :)

But sometimes elegance and speed do coincide. You could show them:
    * chameneos
    * pidigits
    * binary-trees
    * cheap-concurrency
    * partial-sums

rather than the nasty IO problems.
  
> I think there's a big-fat-lesson about the tension between abstraction 
> and implementation in these entries.
> 
> On one hand we've got "This is what I want", on the other it's "What do 
> I have to do to implement it".

Fair enough. 

I think my point is that the examples you point to illustrate the main
problem we've had: fast, heavy duty IO and fast mutable unboxed arrays.

We can expect improvements on both these issues in the next few months.

-- Don