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 E3DBDBC88 for ; Fri, 4 Feb 2005 03:31:47 +0100 (CET) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j142Vl6t010381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Feb 2005 03:31:47 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1CwtG6-0008ow-Jf for caml-list@yquem.inria.fr; Fri, 04 Feb 2005 02:31:46 +0000 From: Jon Harrop Organization: University of Cambridge To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Estimating the size of the ocaml community Date: Fri, 4 Feb 2005 02:33:40 +0000 User-Agent: KMail/1.7.1 References: <891bd33905020213315a2ebb18@mail.gmail.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502040233.40444.jon@jdh30.plus.com> X-Miltered: at concorde with ID 4202DE93.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 recursion:01 statically:01 rewriting:01 infeasible:01 checker:01 debugging:01 vastly:01 minor:01 trade-off:01 overloading:01 bool: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 Thursday 03 February 2005 21:16, Thomas Fischbacher 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: > On the other hand, I cannot just have e.g. a function like > POSITION-IF that returns a number or nil. (Either one has to work with > exceptions, or wrap things up using the Maybe monad. Exception techniques > may interfere badly with tail recursion in some cases.) I think you will find that "int option" does exactly what you want whilst also statically type checking the result. Let me recite my personal experience with static type checking. A couple of years ago, C++ was my latest language. I developed a significant project in C++ until I realised that the core of my implementation was fundamentally flawed and needed rewriting in order to achieve my objectives. This rewrite would have taken over a month. Thus, I gave up. Later, I decided to learn ocaml and porting my project seemed like a worthy task. The ported code was 1/4 as long and almost as fast. I've made two more fundamental changes since then, both of which would have been infeasible in C++. When using C++, I always had to restrain myself from making major changes, as they were bound to break the program and were often irreparable. In contrast, when I make a fundamental change to the ocaml implementation, the static type checker immediately leads me to all of the new misuses of the altered code. This allows me to make much deeper changes without having to worry about spending months debugging the surrounding code. The last time I made such a change it took a day to get the program working again, rather than a month. Thanks to all these major changes, the latest ocaml version is vastly faster than the old C++. :-) > (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". > (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. I shall remain skeptical that GCaml improves upon this solution this until I get to write a decent-sized project in GCaml. I am keen to see GCaml though. > Furthermore, it seems a bit > inconsistent, as on the other hand, we have e.g. < and not '_a -> '_a for some 'a whereas the comparisons have types 'a -> 'a -> bool for all 'a. This is because arithmetic operators are well-defined for some types (e.g. int and float) but there are well-defined comparison operators for all but some types (i.e. except closures). Hence the use of monomorphic and polymorphic types (and exceptions), respectively. Again, this has already been discussed at length on the mailing list. On Thursday 03 February 2005 23:22, Thomas Fischbacher wrote: > > type position = Position of int | None;; > > That is isomorphic to a straightforward application of the Maybe monad, > I'd say. After all, you are just boxing up your int here. Furthermore, you > have to define that particular type globally, as far as I understand it. Use the "'a option" type defined in Pervasives. > > 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. On Thursday 03 February 2005 23:39, Richard Jones wrote: > On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote: > > Oh, by the way, there is one more thing which I consider a really > > grave issue, which gave us quite a lot of grey hair already: Ocaml > > strings have this stupid limitation to 16 MB, which means in particular > > that if you serialize a truly large intermediate state of, say, a long > > and complicated calculation which accidentally got a bit larger than this > > limit (while you did not expect that), well... > > Got to agree with you on this one ... At least we'll soon all be > using 64 bit computers where OCaml doesn't suffer this limitation. Yes. In the mean time, I'm using lists of O(1)-length strings, which is working well. I'd obviously like more comprehensive standard library and bindings to other libraries but, as far as the core language goes, I vote for (for these reasons): 1. Arbitrary-length strings and arrays. (robustness) 2. Version- and type-safe marshalling. (robustness) 3. Compiler warnings when run-time type errors may occur, e.g. when marshalling a data structure which might contain a closure. (robustness) 4. Extensible strings and arrays. (asymptotic complexity) 5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity) 6. Dynamic code generation. (to ease compiler writing) 7. More optimisation, e.g. inlining across functors built-in to the compiler. (performance) If there were a redesign, I'd ask for "string" as "char array" and monomorphisation of polymorphic functions. Perhaps the latter can be achieved with a preprocessor? Anyhow, despite these few and minor shortcomings, OCaml is by far the best language I have ever come across. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd.