From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 68E90BC88 for ; Fri, 4 Feb 2005 10:29:57 +0100 (CET) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j149TuDY031572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Feb 2005 10:29:57 +0100 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 930E120030; Fri, 4 Feb 2005 10:29:56 +0100 (CET) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06591-01-49; Fri, 4 Feb 2005 10:29:54 +0100 (CET) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id D80D020031; Fri, 4 Feb 2005 10:29:53 +0100 (CET) Received: from eiger.cip.physik.uni-muenchen.de (eiger.cip.physik.uni-muenchen.de [141.84.136.54]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id D06B926E87; Fri, 4 Feb 2005 10:29:53 +0100 (CET) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id C1B003CBC; Fri, 4 Feb 2005 10:29:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id BEE862D716; Fri, 4 Feb 2005 10:29:53 +0100 (CET) Date: Fri, 4 Feb 2005 10:29:53 +0100 (CET) From: Thomas Fischbacher To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Estimating the size of the ocaml community In-Reply-To: <200502040233.40444.jon@jdh30.plus.com> Message-ID: References: <891bd33905020213315a2ebb18@mail.gmail.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> <200502040233.40444.jon@jdh30.plus.com> X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at concorde with ID 42034094.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 wrote:01 ocaml:01 subset:01 haskell:01 sml:01 sml:01 compiler:01 statically:01 real-world:01 minor:01 behaves:01 emulated:01 trade-off: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: On Fri, 4 Feb 2005, Jon Harrop wrote: > > (3) The type system is annoying. People claim it helps catching errors, > > but my impression is it only catches those which I would never make > > anyway. > > Static type checking is completely fundamental to OCaml. Consequently, I think > that's a really silly thing to say here but your next comment implies that > you don't know what static type checking is for: Well, I might want to differ here, but I should perhaps also add that I indeed do only know about as much about the structure of the Hindley-Milner-like type system of Ocaml as is the common subset of Haskell, SML/NJ and Ocaml. Yes, it's fundamental to those languages, and indeed I originally thought this would be a great thing, years ago, when I came to SML/NJ from C++. Right now, after a few years of Lisp experience, my personal impression is that actually, it is more a hindrance than a help. But of course, one may always say that we Lisp hackers just are spoilt by our language in this aspect. By the way, Paul Graham seems not to like the ML family for about precisely the same reason. 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". (2) Give the compiler hints how to optimize certain manipulations in terms of machine instructions. Concerning (1), from the machine point of view, there is no difference between a floatingpoint number representing a length in meters and a floatingpoint number representing a length in feet. Nevertheless, one should not blindly add the one to the other, as NASA by now surely can tell you. And indeed, the system of physical units, be it SI or something even more elaborate, exists precisely to prevent such problems, yet there are aspects of this "type system", which has proven its value, which can not be mapped to Hindley-Milner. If I multiply a speed (in m/s) with a mass (in kg), I get a momentum (in kg m/s), which I neither can sensibly add to a speed, or a mass. If I further consider a change in momentum with time, I automatically get something with units kg m/s^2, that is, a force. Of course, I could introduce types for all intermediate quantities which I will encounter in a problem statically. However, there are many problems where I do not know a priori which quantities will appear with which powers, hence I would like to have this with full dynamical flexibility. Please prove me wrong if I am missing something here, but to me it seems that even for this simple "real-world type system" example, there is no way to directly map this to H.M. in the way explained here. And this is only *one* example. There are many more, of structures that morally qualify as type systems, but cannot be related to H.M. > > (4) There are a few other minor issues, such as a lack of > > multiple-value-bind, which I personally find slightly annoying, but > > not essential. > > I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, > 2, 3". Let's take a specific example. * (/ 1234 100) 617/50 * (round 1234 100) 12 34 The division function in LISP returns one value. The ROUND function returns two. If I use it as in * (+ 5 (round 1234 100)) 17 it behaves as if it were a function that gives me only the primary value. But if I want it, I also can bind and process the secondary (or even higher) extra values returned by that function. So it's even more than "just returning more than one value without having to cons" (which already is quite nice - but this essentially can always be emulated via going to CPS, which establishes full call/return symmetry). It's about giviny gou extra choice. Either: "Nice that you can also provide me extra information, but I really don't care here", or: "I can as well make use of this other piece of information which you already obtained anyway." Same function, same call. > > (9) It really annoys having +, +., and +/. > > There is a trade-off between type checking and operator overloading. This has > been discussed at great length before and a lot of interesting information > can be found by perusing the mailing list archives. Sure. I don't quite know what to think about Haskell's type classes, but superficially it feels quite much more convenient. Anyway, it may as well be here that the impression which one gets by working heavily with it is a different one, so I'll keep an eye on that but surely not take it as the only True Revelation. > > > I don't see how this and Printf are substantially different (except that > > > Printf is type safe), > > > could you elaborate? > > > > Erm, what do you do if you want to quickly debug-print a list of vectors > > of pairs? > > Use the top-level. That entirely misses the point! I talked about getting debug traces from an involved run. > Anyhow, despite these few and minor shortcomings, OCaml is by far the best > language I have ever come across. Nice if it suits you well. I personally experience some friction with it, however. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)