On Tue 12 Oct, Kevin Atkinson wrote:
> 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.
I have mixed feelings about uniqueness typing. The idea of unique values
seems a strange and unnatural to me. But it also seems essential if you're
going to treat IO as purely functional computation.
> 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.
My own feeling is that unless uniqueness typing is semantically necessary,
(as I understand it is in Clean) it should be kept out. But I can't see
any reason why Haskell compilers shouldn't exploit optimisations based on
uniqueness analysis. Ideally I would prefer to have the effeciency problem
fixed by designing better compilers instead of further complexification
of the type system.
However, I suspect that in practice a good programmer will be able to do
this better than compilers can for some time yet. This is really why C is
'faster' than Haskell (although code effeciency or lack of it is really a
property of compilers and programmers of course, not languages).
So maybe, as you say, uniqueness typing would be useful in Haskell.
It seems to give Clean a speed advantage for number/array crunching at
present (or so I've heard, though I must confess I've never tried it in
either language).
Regards
--
Adrian Hey
