Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Estimating the size of the ocaml community
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-02-04 (10:26)
From: Andreas Rossberg <rossberg@p...>
Subject: Re: [Caml-list] Estimating the size of the ocaml community
Thomas Fischbacher wrote:
> One issue with the type system is that, looking closely, there are at 
> least two (perhaps three) very different tasks it tries to do, which 
> superficially look like being the same, but actually are very different, 
> and indeed, in many situations, it may be much more appropriate to 
> address them specifically and individually than with an unified approach.
> (1) Prevent the programmer from "accidentally plugging an electrical 
> shaver into a power high-voltage outlet".

In my personal experience, this is absolutely essential when you go 
higher-order in non-trivial ways - dynamic type errors won't give you 
the slightest clue when you screw up some combinator plugging. 
(Incidentally, Lisp also isn't very well suited for higher-order 
programming, because of its syntax issues: no light-weight application 
syntax and currying.)

> (2) Give the compiler hints how to optimize certain manipulations in terms 
> of machine instructions.

The latter is actually the least important point. More significant are:

(3) Verified documentation. Provide a stylised language for describing 
interfaces, and have the compiler actually check these "comments", so 
that they never get out of date.

(4) Maintenance. Provide guidance when modifying a program non-locally 
by letting the compiler point out the locations of the minimum set of 
obliged changes.

(5) Abstraction. Enable the programmer to define her own abstract types, 
for compile-time encapsulation and invariant enforcement.

The latter is also known as "typeful programming" (cf. Luca Cardelli's 
seminal article of the same name). That is where advanced type systems 
really start to score, and what people with arguments of the sort "a 
type system only catches trivial errors" usually overlook completely.

Type abstraction may not be powerful enough to fully capture units, but 
it goes a long way. And you cannot seriously argue that something is 
useless because it does not cover everything.

Andreas Rossberg,

Let's get rid of those possible thingies!  -- TB