On Wed, Sep 01, 1999 at 11:16:05AM -0700, Nick Kallen wrote:
> > a <- b
> > c <- f a
> >
> > as
> >
> > c <- f b
> >
> > In Haskell I can't. Why? b is of type IO something, whereas f expects a
> > non-monadic argument.
>
> I don't see why this is any different from say, Pascal, where you can't:
>
> Writeln(Readln(a));
You don't? My Pascal is rusty (I haven't written anything with it
in years), but IIRC ReadLn is a procedure and does not return a value.
The Haskell function getLine returns a value, and in the do notation
a <- getLine
looks to the naive beginner like that value is put into the a variable.
Indeed, something is put there, which adds to the confusion.
In contrast, in Pascal, you can't IIRC write
a := ReadLn;
Actually, if you could, then your
WriteLn(ReadLn);
would be perfectly OK, which *again* adds to the confusion. The Haskell
do notation looks like imperative code (and in particular the arrow
looks like assignment) but it behaves in many respects quite differently.
> This distinction is made clear if the programmer is aware of why he's using
> <- and not =.
Yes. By that time she could as well use (>>=). We're talking about
whether do is better for the beginner than (>>=), not about the usefulness
of do to others.
> most imperative IO libraries make
> a similar distinction anyway since IO functions tend not to return values
> but modify a parameter (i.e., procedure vs. function is no worse!).
The procedure vs function distinction is very clear from the notation,
so it's not a valid point for comparison.
> Plus, you can just sidestep the whole issue: no explanation, just say that
> equality laws don't hold for <-.
Equality laws do not hold for imperative assignment either.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
""
(John Cage)
