On Mon 24 Jan, Pablo E. Martinez Lopez wrote:
> In Haskell you ONLY define a VALUE of an abstract type IO that DESCRIBES
> the changes the World would suffer WHEN that value is operationally
> interpreted. So, saying that Haskell is incapable of describing I/O is,
> at least, a misunderstanding.
Probably so, I do have difficulty understanding this. The point I was
trying to make is that as far as Haskell is concerned, that there is no
difference between values of type (IO a) and any other values. The fact
that once evaluated these values cause IO operations to be performed (by
some entity outside the Haskell program) is irrelevant. This is, of course,
merely what I understand as the Haskell view from other correspondants on
this list, not an indisputable truth.
> That abstract type can be viewed as a state monad whose state is the
> World, i.e.
> IO a = (World -> (a, World))
> and so you can also describe functions going from one state of the world
> to another (producing a value as result), but only in abstract ways.
I was recently assured (by a message on this list) that as far as Haskell
is concerned a value of type (IO a) is simply an abstract data type, not
a world transforming function. But if you do interpret it as such, what
you've got is world as value IO, like Clean.
> I don't know how does Clean work with I/O, and I can not conlude
> anything from your explanation,
I wasn't trying to properly describe Clean IO and I won't because it will
take to long. The message was just MHO re. some pros & cons.
> nor I can see how they colud manage to
> avoid the 'horrors' of imperative languages you attach to Haskell. I
> would appreciate more insight in this subject.
I attach the horrors to the non-Haskell outside entity (the IO monad machine),
not to Haskell. (I assume we forgive the performUnsafeIO or whatever it's
called). BTW, I would not assert that Clean IO is horror free, but many people
would.
Regards
--
Adrian Hey
