From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 91B9CBC88 for ; Fri, 4 Feb 2005 11:26:21 +0100 (CET) Received: from justus.rz.uni-saarland.de (justus.rz.uni-saarland.de [134.96.7.31]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j14AQLYV023077 for ; Fri, 4 Feb 2005 11:26:21 +0100 Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.254.254]) by justus.rz.uni-saarland.de (8.12.10/8.12.10) with ESMTP id j14AQKZH3038658 for ; Fri, 4 Feb 2005 11:26:20 +0100 (CET) Received: from mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.13.3/2005011400) with ESMTP id j14AQIM5013489 for ; Fri, 4 Feb 2005 11:26:19 +0100 (CET) Received: from ps.uni-sb.de (grizzly.ps.uni-sb.de [134.96.186.68]) by mail.cs.uni-sb.de (8.13.3/2005011400) with ESMTP id j14AQIsa006954 for ; Fri, 4 Feb 2005 11:26:18 +0100 (CET) X-Authentication-Warning: mail.cs.uni-sb.de: Host grizzly.ps.uni-sb.de [134.96.186.68] claimed to be ps.uni-sb.de Received: from ps.uni-sb.de (groove.ps.uni-sb.de [134.96.186.172]) by ps.uni-sb.de (8.12.10/8.12.10) with ESMTP id j14AQDow006204; Fri, 4 Feb 2005 11:26:13 +0100 Message-ID: <42034DC5.70005@ps.uni-sb.de> Date: Fri, 04 Feb 2005 11:26:13 +0100 From: Andreas Rossberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Estimating the size of the ocaml community References: <891bd33905020213315a2ebb18@mail.gmail.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> <200502040233.40444.jon@jdh30.plus.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.1 (justus.rz.uni-saarland.de [134.96.7.31]); Fri, 04 Feb 2005 11:26:20 +0100 (CET) X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.29.0.8; VDF 6.29.0.101 X-Miltered: at nez-perce with ID 42034DCD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; rossberg:01 rossberg:01 caml-list:01 ocaml:01 wrote:01 higher-order:01 non-trivial:01 combinator:01 higher-order:01 syntax:01 syntax:01 compiler:01 compiler:01 abstraction:01 compile-time:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: 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, rossberg@ps.uni-sb.de Let's get rid of those possible thingies! -- TB