As a professional programmer who has to read and make sense of
other people's C++ code on a daily basis I want to promote the
idea that good *interactive* software tools can address many of
the issues with undecidable type checking. I completely agree
the more checking that gets done the better---but why the batch
mode model of the 1960's?
1. If the tool can resolve the types (and I would expect this
to be true most of the time) it can display the types and (if
the user or style guide dictates) add the types to the source.
2. If the tool can not resolve the type of a particular
construct then the programmer can add the information and
the tool can verify that the supplied type is correct.
3. As D. Tweed's short STL example points out, C++ can be all
but unreadable without the support of static analysis tools
today (oohhhhh... there was an implicit constructor call there!!!).
I would argue that working with large software systems in any
language requires support from software tools. So why not
design Haskell-2 with tools in mind?
D. Tweed wrote:
>
> On Wed, 17 Feb 1999, michael abbott wrote:
>
> > As a C++ user (with a background in categories) patiently waiting for
> > something a lot better, I personally favour two principles:
> > 1. let's go for undecidable type checking. I want the compiler to be able
> > to do as much work as possible: ideally, everything that can be resolved at
> > compile time should be if only we can express this correctly.
*snip*
> (1) The compiler catches as many language inconsistencies as possible
> rather than resolving them in possibly incorrect ways.
Agreed with both.
> (2) A program should be as easily readible as reasonably possible,
> which strongly suggests as free for `noise' as possible.
I agree with the sentiment.
> (For example, try doing simple things with the pair STL class and see how
> soon relatively simple expressions become incredibly opaque because of the
Strongly agree, also the multi-line type names disgorged by the C++
compilers when you have an error message are extremely cumbersome.
> I'd prefer only to have to put in type decls for identifiers only when the
> compiler genuinely can't use a simple algorithm to deduce the unique
> interpretation that fits,PROVIDING THIS ALGORITHM IS SUFFICIENTLY SIMPLE
> THAT YOU CAN APPLY IT IN YOUR HEAD. If not then I suppose being explicit
> everywhere does become a better way to go.
I would change this to 'the tool can pinpoint the problem to the point
where the algorithm becomes obvious'. I now always use signatures
when working with SML functors, but the few times I did not the error
messages from SML-NJ compiler wouldn't really help me identify the
problem until I issolated it by adding explicit types.
