[Shootout-list] Haskell killer prodcons implementation - fair?

[Raymond Racine]

On Sun, 2004-10-03 at 04:11, Einar Karttunen wrote:
> On 03.10 01:49, Raymond Racine wrote:
> > BTW I think the latest Haskell version is hand waving the
> > consumer/producer count/increment requirement a tad.  Though I agree the
> > mVar approach itself is fair.

Agreed on the count inc/dec flag.  I am referring to the pseudo code for
the prodcons tests which specifies a consumed up counter and a produced
up counter.   It is the value of these counters which is to be returned
by the test.

The Haskell version (I believe) simply returns the inputted n value for
the consumed counter then reads n-1 produced i's, and returns the nth
mVar value for the produced counter.  This is at odds with the pseudo
code.

Two Points:
1) While we may question the nature of the test specification, it is
what it is. While Haskell version does address the the true intent of
the test, it is not fully following all of the test's specifications. 

2) Normally this is a nuanced triviality in most languages x:=x+1,
however a simple counter in Haskell is not so simple!  

So while Haskell offers efficient list comprehensions with laziness that
supported writing concise elegant code for the solution, it's
functionally transparent pureness makes side effecting I/O, like a
simple counter, more of a challenge.  

Therefore, IMHO, it is fair that languages which support side effecting
I/O concisely and elegantly with statements or ref cells should not be
punished because they do have to do loops or recursive calls to perform
what Haskell is doing with a simple list comprehension.  Dealing with
those counters with two additional mVars (or alternative means) will
clutter up the current solution but it is an aspect of Haskell
programming (dealing with side effecting I/O) that should not be hand
waved away.

Ray