> 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.
Exactly. That is a powerful thing: you treat computations as values and
other guy is responsible for execute them. Recall: the type (IO a) is
that of PROGRAMS performing I/O, but the EXECUTION of those programs is
another matter. And as Simon Marlow pointed out, you have NO means to
produce that execution other that binding your IO to Main.main.
> The fact that once evaluated these values cause IO operations to be performed (by
> some entity outside the Haskell program) is irrelevant.
>From Haskell point of view, yes, it is irrelevant. But for the
programmer that wants those operations performed it is not. You can have
a function returning some IO, and when that function is applied to your
data, a suitable program is produced AND executed.
That allows nice algebraic descriptions of, for example, a WWW site, and
a 'compilation' function that takes such a representation and returns a
IO value that, when executed, produces the right pages in the right
directories.
> > 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.
Note that I say "only in abstract ways" which means that (IO a) IS an
abstract type. But you still could view/understand it as a world
transforming function for which you have no direct acces as a programmer
-- only the abstract operations. That means that you have NOT access to
the value World, only to the functions transforming it.
And Simon Marlow said that almost any implementation use a variant of
this intepretation.
> > 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.
Ok. But in order to understand your remark, the ways Clean works is
needed, and not everybody does so. I would appreciate if someone could
explain it easily.
> 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.
The non-Haskell outside entity is still there for a Haskell programmer,
so she should think and use its 'horrors'. I'm not sure if stateful
computations (graphical interfaces, WWW programming, etc) could get rid
of those horrors...
The 'function' unsafePerformIO is not Haskell, but GHC. Which brings me
to other line of argument: if someone use things appearing in the
Haskell report ONLY, then her programs should work in any Haskell
compiler. But if she wants to use the extensions provided with a
specific compiler, then it is clear that she is sacrificing portability.
Fidel.
