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 5BEB3BC32 for ; Thu, 17 Mar 2005 11:15:19 +0100 (CET) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2HAFIPQ021688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Mar 2005 11:15:19 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1DBs29-0001Dq-4v for caml-list@yquem.inria.fr; Thu, 17 Mar 2005 10:15:17 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml troll on Slashdot Date: Thu, 17 Mar 2005 10:16:17 +0000 User-Agent: KMail/1.7.1 References: <20050316001819.GB347@first.in-berlin.de> <891bd33905031619484825e276@mail.gmail.com> In-Reply-To: <891bd33905031619484825e276@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503171016.18310.jon@ffconsultancy.com> X-Miltered: at nez-perce with ID 423958B6.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 yaron:01 minsky:01 stack:01 ocaml:01 stack:01 iirc:01 non-trivial:01 inlining:01 recursion:01 optimising:01 recursion:01 trivial:01 48,:98 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 17 March 2005 03:48, Yaron Minsky wrote: > On Wed, 16 Mar 2005 19:35:17 -0800 (PST), brogoff > wrote: > > Anyways, long lists do occur, and Stack_overflow at the customer site > > sucketh bigtime. > > I completely agree. As someone who makes extensive use of OCaml in a > business setting, the fact that the standard libraries throw > exceptions on large data structures is a real pain. I believe the Stack_overflow exception is not necessarily thrown - the process may simply die. IIRC, I found this on x86 Debian Linux when swap was turned off. > It's a violation > of the principle of least surprise, and I've run into it in practice > quite a few times. I understand your (and Brian's) concern but I think the solution is to be more careful when programming, rather than to replace all of the library functions. That seems like a sledgehammer to crack a nut to me... > Our solution was to just rewrite the list module > with tail-recursive versions. I would recommend using and making documentation instead, as non-tail-recursive functions can be very useful. In non-trivial code I would recommend putting the asymptotic complexity of stack use in the docs. > We're happy to make the performance > tradeoff. If we really want things to be fast, List.map is no good > anyway, due to the lack of inlining of the function parameter. Yes, if your program uses non-tail-recursive functions with very deep recursion then it will be much slower anyway. Consequently, you are likely to fix this whilst optimising anyway. As Brian has said before, users can throw you a sideball by giving input which requires deep recursion by a non-tail-recursive function which had not been expected by the programmer. Provided you are thorough, this shouldn't happen though. I must say that I've had fewer stack problems with my OCaml code than with code I've used in other languages... > I do think that it would be a great thing if the tail-recursive list > functions were moved into the standard library. I would not like to see trivial tail-recursive alternatives put into the library (e.g. let map f l = rev_map f (rev l)). I think it would bloat the library unnecessarily and they are often not the best solution, particularly in combination. For example, writing these functions yourself makes a rev rev and the following deforestation obvious. Given that these are likely to be performance-critical functions, this is obviously useful. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists