From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 9783BBC88 for ; Sat, 5 Feb 2005 22:48:44 +0100 (CET) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j15LmhrJ003165 for ; Sat, 5 Feb 2005 22:48:44 +0100 Received: by rproxy.gmail.com with SMTP id c16so788477rne for ; Sat, 05 Feb 2005 13:48:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZUTO8OhFYselyGW/aBLz7jKj+ayqNULip/YWMB0Oewuq+BHqO9YIFg7cjIJLWQgfEjz2HuTFfbOlx1UNXVkobINTCIHNDo84ln3ObLeJTbIhyALE6FSkgQugAz1Xlltrnx8vtQV7Ru19tuShFP8Pm0aR7aOALkQDc97M2nRKsW0= Received: by 10.38.152.6 with SMTP id z6mr350780rnd; Sat, 05 Feb 2005 13:48:43 -0800 (PST) Received: by 10.38.86.80 with HTTP; Sat, 5 Feb 2005 13:48:43 -0800 (PST) Message-ID: <877e9a1705020513486111192f@mail.gmail.com> Date: Sat, 5 Feb 2005 16:48:43 -0500 From: Michael Walter Reply-To: Michael Walter To: Jon Harrop Subject: Re: [Caml-list] The boon of static type checking Cc: caml-list@yquem.inria.fr In-Reply-To: <200502041026.56107.jon@jdh30.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <891bd33905020213315a2ebb18@mail.gmail.com> <877e9a170502031856175260c8@mail.gmail.com> <877e9a17050203185674680413@mail.gmail.com> <200502041026.56107.jon@jdh30.plus.com> X-Miltered: at nez-perce with ID 42053F3B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 abstractions:01 iirc:01 stl:01 stl:01 ocaml:01 checker:01 statically:01 polymorphism:01 ocaml:01 trivial:01 subtyping:01 ad-hoc:01 polymorphism: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=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop wrote: > > Are you using heavy casting and such without proper abstractions in > > your C++ code? > > No. The code is freely available here: > > http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/smoke/index.html Unfortunately I don't really have time to check that out to an adequate extent :( > > Pr what kind of changes did you want to make? > > IIRC, one development was to change the core data structure from a list to a > tree. The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC > in stl_tree.h and stl_map.h vs 198 LOC in map.ml). My ocaml implementation > uses trees and graphs throughout now. Hmm, ok. > > How did > > you feel that the static type checker of C++ didn't provide you with > > similar help? > > As the C++ type system cannot represent (and, therefore, statically check) > polymorphism properly, altering a generic data structure expressed using > templates results in reams of errors, mostly pointing to wrong places. In > contrast, the worst I get with ocaml is an error in the wrong place because a > previous function has been inferred to have a wrong type. Even this problem > is much less common and trivial to trace. Also, it would be even easier to > solve with an IDE which threw up the inferred types. Hrm.. it handles both subtyping and ad-hoc polymorphism. I agree, with templates the error messages are not easy to read (it gets a lot better with experience, but I understand that that is not an argument). > As the C++ type system cannot represent (and, therefore, statically check) > modules and variant types, shoehorning solutions into using class hierarchies > and being forced to use pointers results in verbose code and weaker type > checking. In contrast, the equivalent ocaml code is succinct and thoroughly > checked. This brevity can also be attributed to the ability to pattern match. Admittedly the lack of modules is a bit of a pain (although one can do very tricks by combing #include + templates to work around the lack of macros :-). Also, the lack of algebraic data types/variants (besides pointers a.k.a. T option;) in the core language is certainly bit annoying. boost::variant<> appears to solve that problem very well, though. > Obviously such problems would have been virtually impossible to weed out had I > chosen to use a language with dynamic type checking, which is precisely I why > I left such languages at the door many years ago... Although I'm using Python for a lot of my scripting purposes, I definitely prefer statically typed languages for mid-size to larger projects as well. Maybe I'm just weak, but the type system gives me much (I second that other post which mentioned that static typing is not only about type checking, but also about "compiler-verified code documentation" and much more). :-) > > > I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c > > > = 1, 2, 3". > > > > It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also > > does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c > > is bound to nil). > > These seem pretty pointless to me, but what about: > > # let {a=a; b=b; c=_} = expr;; > > or > > # let x = expr in > ... x.a ... x.b ...;; > > and then > > # let (a, b), c = expr, None;; > > (if you must). I was merely explaining its semantics (giving you a free google, so to say ;-), without any judgement about its usefulness compared to O'caml alternatives. Regards, Michael