Hi
> Ben Rudiak-Gould wrote:
>> > ... we can't even determine the meaning of a correct
> > program without looking at explicit type signatures.
>Johannes Waldmann wrote:
> So what? Can we do this in other languages?
> Do we want it? I think not.
>> The Haskell design (of type inference rather than type checking)
> has the strange feeling of "our types are so strong that
> you can completely avoid (writing) them".
> To me, this seems contrary to sound software engineering.
To a large extent, I would agree with this remark. It seems to
me that
(1) We should write types when we are telling the compiler
what the plan is.
(2) We should not need to write types (or at least not often)
to convince the compiler that we are following the
plan.
Indeed, if one replaces `compiler' in the above by `editor',
one begins to discover that the writing of an explicit
type signature can assist us in determining not merely
the meaning of a correct program, but the program itself.
The writing of explicit type signatures (and in particular,
class constraints) serves more than the practical necessity
of helping a dim computer to cope and more than the moral
purpose of disciplined documentation. It gives programmers
a very compact language for describing a great deal of
tedious plumbing. That's really good.
Types are not and should not be regarded as passive things
which machines check and programmers try to ignore. One only
needs to look at what, in toto, Haskell compilers actually
do with types (let alone what editors could do), to see that
writing a type can be a highly effective act of programming,
and hence that reading types can be a very efficient means
of program comprehension.
It's not types we should be not reading or not writing: it's
the boring bits of programs.
Cheers
Conor