Hi Mike,

I daresay there are only two people on this list who use Haskell,  
myself and Eric de Castro Lopo.  And now you, of course.  If I've  
missed anyone, I'd like to hear from them as well.

On a practical matter, the Yale group has promised the release of an  
arrow-based hasSound package this summer.  I haven't seen the  
interface, but it sounds like a Haskell-based EDSL inspired by CSound  
(and also probably Yampa).  From what I've heard so far, they're  
working on an arrow pre-processor to do some optimizations before it's  
ready for release, but it's close.  I'm very excited about this  
release; I'd started something similar myself before I found out  
they'd beaten me to it.

(I apologize if the rest is a bit off-topic for this list.  Please  
feel free to skip.)

My biggest impediment in using Haskell for what I want to do is that I  
got sidetracked by the promise of functional programming.  Really  
cool, high-level specifications, blah blah blah.  But it's not quite  
there yet.  As of now, I think that by using Haskell instead of e.g. C  
or Java, you trade one set of problems for a different set of  
problems.  Other languages (Lisp, maybe ML) can offer the features and  
problems of both depending on how you use them.

Seen this way, the standard answer would be that you now have at least  
one (possibly many) more tools in your toolbox, making you that much  
better/more efficient at programming *provided you pick the  
appropriate tool for the job*.  Even if you don't use Haskell, simply  
by learning to think in a functional manner you've gained skill that  
can apply to programming in any language when appropriate.  Although  
I'd be surprised if you ever wanted to use the verbosity of Java after  
being exposed to Haskell.

In my case, I'm not particularly happy with any of the ways of doing  
audio file I/O in Haskell; they're either too imperative (i.e.  
non-functional) or rely on the evilness that is lazy I/O.  So I've  
been experimenting trying to find an I/O model that I like.   
Enumerators seem good, but they're a bit new at the moment and still  
being worked out.  Meaning I'm spending time on enumerators instead of  
what I wanted to do in Haskell in the first place.  That's okay  
because in a sense it's exploratory work for how I want to structure  
the whole project; I just wish I had more time to spend on the  
programming.

For the record, I consider lazy I/O to be sort of like pointers in C.   
They're extremely powerful and an iconic feature of the language.  C  
wouldn't be C without pointers, and Haskell wouldn't be Haskell  
without laziness (esp. lazy I/O).  However, they require a certain  
amount of caution because if you don't use them properly they lead to  
problems, ones which are treacherous for newbies and insidious for  
veterans.  Despite these problems, they are arduously defended by the  
language's users and designers for their power and usefulness.  Lazy  
I/O can be safe just like pointers can be, but to use them properly  
requires reasoning about the language's mechanics, not the high-level  
specification of the problem that FP-ers are supposed to be value.  I  
just wonder how many times Don Stewart needs to tell bytestring users  
to force evaluation of their data, or "half-closed" handles need to be  
explained on haskell-cafe before all the Haskellers see lazy I/O this  
way.

Cheers,
John L.


Quoting Michael P Mossey <mpm@alumni.caltech.edu>:

> I've made some progress. Maybe the biggest progress is that I don't
> tremble in fear when I see statements like "Applicative functors are
> also pointed when defined on a monoid."
>
> But, I'm beginning to wonder if there is really a practical payoff for
> what I want to do. I would be interested in hearing from the member(s)
> on this list who use Haskell.
>
> Thanks,
> Mike
>