From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 76B26BC0B for ; Tue, 16 Jan 2007 03:12:44 +0100 (CET) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0G2ChU9022919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jan 2007 03:12:44 +0100 Received: from [80.229.56.224] (helo=[10.0.0.5]) by ptb-relay01.plus.net with esmtp (Exim) id 1H6doZ-0001Ho-Fm for caml-list@yquem.inria.fr; Tue, 16 Jan 2007 02:12:43 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ocaml compiler features Date: Tue, 16 Jan 2007 02:11:02 +0000 User-Agent: KMail/1.9.5 References: <45A87011.8080203@gmail.com> <20070115221717.GA9982@snarc.org> <1168910291.9207.62.camel@rosella.wigram> In-Reply-To: <1168910291.9207.62.camel@rosella.wigram> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701160211.02613.jon@ffconsultancy.com> X-Miltered: at discorde with ID 45AC349B.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 0100,:01 ocaml:01 syntax:01 syntax:01 recursive:01 recursive:01 segfaults:01 stdlib:01 100,000:98 frog:98 wrote:01 wrote:01 sticking:01 On Tuesday 16 January 2007 01:18, skaller wrote: > On Mon, 2007-01-15 at 23:17 +0100, Vincent Hanquez wrote: > > On Mon, Jan 15, 2007 at 12:23:32PM -0800, Martin Jambon wrote: > > > OCaml is well-enough designed so that there is no "common" syntax > > > extension. > > > > There ARE common syntax extensions. > > how many people miss a try-except-finally construct ? > > how many people miss a return statement to break the flow of a function. > > etc .. > > I don't miss any of those things .. the point being they're > not so 'common' as you might think. try ... finally is useful when closing file handles. However, simply trying to read a file as a list of strings is a sticking point for many newbies because the obvious functional implementations aren't robust: let rec read ch = try input_line ch :: read ch with End_of_file -> [] Elegant but not tail recursive. Conventional transformation into tail recursive form using an accumulator: let rec read ?(t=[]) ch = try read ~t:(input_line ch::t) ch with End_of_file -> t Still not tail recursive because tail calls inside a try block are not optimised, so it still segfaults when the file has >100,000 lines on a 64-bit machine. Solution is to box and unbox, moving the tail-recursive call outside the try block: let rec read ?(t=[]) ch = match try Some(input_line ch) with End_of_file -> None with | Some h -> read ~t:(h::t) | None -> t Inelegant. We really want a File.fold function to fold over the lines of the file, and a cons function: File.fold cons ch [] I have a much bigger wish list for functions than I do for syntax. I'd like the stdlib functions to be tail recursive, more comprehensive and faster... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists