Lars Lundgren wrote:
>
> On Mon, 11 Oct 1999, Adrian Hey wrote:
>
> > On Mon 11 Oct, Lars Lundgren wrote:
> > > I'm sure a lot of poeple have gotten this wrong. I would be surprised if
> > > not all the experienced haskellers has this view though.
> >
> > Probably so, but this view seems in complete contradiction to
> > that of the Clean world. So I'm still confused :-)
> >
>
> I just took a glance at Clean. (Glanced through "The Ins and Outs of Clean
> I/O" by Peter Achten and Rinus Plasmeijer.) I think their solution with
> unique types is really neat.
>
> One downside may be that they have made the type system more complex
> since it has to handle all the uniqness tags.
>
> They deal with side effects (IO) by tagging the values with * and calling
> them unique. Haskell deals with side effects (IO) by using an abstract
> data type IO a which denotes an action [with clean type *World ->
> (a,*World) ]. In both cases, the compiler is notified that it is not ok to
> change order of evaluation.
>
> In the Related work section, they mention Monadic IO and writes "To our
> knowledge combining monads of different type is a rather tedious task..."
>
> I'm reluctant to say that I agree. I have written a few programs using
> monad transformers and while everything works in principle, it is, well -
> tedious...
>
> I also do not like the tendency to put more things in the IO monad (I'm
> thinking about the extensions with IORef). I like stToIO better, but
> somehow it still feels like a hack. Maybe some library support for monad
> transformers and maybe even some syntactig sugar would do the trick.
>
> They also wrote "[The monadic IO approach] over determines order of
> evaluation". I'm a bit puzzled about that statement. Is it true? Comments
> anyone?
I have been meaning to bring this up for quite some time. I think
Haskell could really benefit from a uniqueness typing system as it would
really simplify many things, such as fast array updates. Also it opens
the door for TONES of optimization opportunities if the compiler can
also mark standard types of being unique, even if the user did not.
Eventually the compiler could become so good at uniqueness identifying
that the user will never have to explicitly mark anything as unique
except in the case where its communication to the outside work. Ie IO
etc. Thus one can write non-destructive array updating programs that
would without an uniqueness type system be horribly inefficient (but
easy to verify as being correct) but with a uniqueness type system will
fast and easy to verify. Can you ask for more?
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
