On Thu 28 May, Fergus Henderson wrote:
> Unbound type variables can lead to runtime errors.
Its difficult to see how they can be always avoided without writing explicit
type signatures to do this.
> A strong type system is supposed to prevent runtime errors.
> Thus it makes sense to disallow anything that might
> result in an attempt to access an unbound type.
Yes, but in the cases we've been talking about we know that there will be
no access to the unbound type since the reason the type is unbound is that
it isn't referenced by expressions such as (Right something). As soon as the
(Right something) becomes an alternative result to (Left somethingelse) then
the type variable will no longer be unbound.
> > What is the ultimate purpose of type checking a program? The answer has
> > to be, to avoid run-time errors. Beyond this, the type system seems to
> > serve no purpose and so should not reject definitions such as that
> > above, in an ideal world.
>
> The Haskell type system is used for much more than just avoiding run-time
> errors. In particular, the Haskell system of type classes means that
> types are part of the semantics.
I'm begining to understand the significance of this point. I suppose
it also means that I couldn't be more wrong in my belief that Haskell is
intended as a target language for code synthesis tools in general. What
these really need is a non-type checked language, ideally (assuming
the synthesised code had somehow been proven to be type safe).
> Some people have argued against this, arguing for a system where
> types do not affect the operational semantics, only the legality.
> But this leads to a less expressive language (for example,
> you can't have a polymorphic `read').
I think I agree with these people. :-(
> > as a general rule, I completely disregard Haskell's class system when ever
> > possible. If this makes me a naive user, then I must plead guilty.
>
> You shouldn't disregard it "when ever possible";
> you should only disregard it in cases where you will
> often want to apply different methods to the same data type.
I know using Haskell Classes will probably result in neater code a lot of
the time. But when I write modules I like to think that they will last
me 'forever', so I try to make them as general purpose as possible in the
hope that they might come in handy again some day. Given the choice between
a neat but non-general way of doing things and a messy but general way I
am always inclined towards the latter. Perhaps its just my temperament
rather than logic that makes me do this :-)
> In many situations, the methods you want are usually fixed for each type,
> and in those sort of situations, it makes sense to use type classes.
Arithmetic being the obvious example. Although, even here it is conceivable
that one might want to employ different multiplication algorithms (for example)
on different occasions, even if the number representation didn't change.
But this is probably rare, I must conceed.
> > I suppose I could probably get around this problem by by making different
> > types using newtype, but I this would no doubt cause other complications
> > elsewhere.
>
> Yes, perhaps. See Alistair Reid's proposal for newtype typecasts
> to avoid some of these complications.
I think I've seen this. It didn't seem to go down to well if my memory
is correct. (I don't mean that as critisism of the Alistair Reid's proposal,
but as a reflection of the fact that there appears to be considerable
diversity of opinion on these issues.)
Regards
--
Adrian Hey
