[Haskell-cafe] Composing functions with runST

[Sebastian Sylvan]

On 1/3/07, David House <dmhouse at gmail.com> wrote:
> On 03/01/07, Seth Gordon <sethg at ropine.com> wrote:
> > So I can't just tell someone who's just starting to learn Haskell that
> > "f $ g y" is equivalent to "f (g y)"; I have to say "those two are
> > *almost always* equivalent, but if you use $ and the compiler complains
> > about not being able to match the expected and the inferred type and a
> > type signature in the error message has the word 'forall', try rewriting
> > that expression without the $ and see if it compiles".  Eeeww.
>
> Why would someone just starting to learn Haskell be using ST? The
> canonical tutorial structure is to start with the pure stuff and only
> introduce the (more complicated!) impure stuff (ST, IORefs, etc.) in
> an 'advanced techniques' or similar section.
>

(slightly OT)

It's true that this is the typical way of learning Haskell, but I for
one think it's a bad way of learning Haskell.
Very few real world programs get by without the "impure" stuff, so if
you give the newbie the impression that it isn't there (by postponing
it) there's a chance he'll run into a situation where he needs it
before it's been even mentioned (queue newbie going "bah, academic
language" and switching to C++).

I find that the Haskell introductions I like the most are the ones
that accompany papers about STM and such. I.e. ones which have to
teach the reader about the basics of Haskell IO, but doesn't have
enough space to start with the pretty stuff. Mix that with some actual
comutations to show off some pretty stuff and you'll have a newbie who
is both excited about the cool looking features of the pure aspects of
Haskell, but completely aware of the fact that you can do impure stuff
as well.

Oh yeah, I agree that the relationship between ($) and (.) is a bit
ugly from the user's perspective. It may have very good reasons, but
I'd prefer consistency towards the user (i.e. spot when someone is
using ($) with higher ranked types and do rewriting) rather than
consistency towards the compiler.

-- 
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862