From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA02609; Fri, 31 Jan 2003 21:34:02 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA02649 for caml-list@pauillac.inria.fr; Fri, 31 Jan 2003 21:34:01 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA01874 for ; Fri, 31 Jan 2003 20:58:12 +0100 (MET) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h0VJwBf14559 for ; Fri, 31 Jan 2003 20:58:11 +0100 (MET) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0VJuJv02504 for ; Fri, 31 Jan 2003 19:56:19 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.hd.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0VJstX27037 for ; Fri, 31 Jan 2003 19:54:55 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003013111582804688 for ; Fri, 31 Jan 2003 11:58:28 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1AW0C8F5>; Fri, 31 Jan 2003 11:58:09 -0800 Message-ID: From: "Harrison, John R" To: caml-list@inria.fr Cc: "Harrison, John R" Subject: RE: [Caml-list] @, List.append, and tail recursion Date: Fri, 31 Jan 2003 11:58:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk How about the following policy? Don't place any limit on stack growth The stack, like the heap, should be capable of expanding to fill all available memory. I don't know much about the OS issues involved in stack extension, but some such policy seems preferable to building in a hard limit. Users would then be free to write relatively inefficient and stack-hungry recursive functions, and at least the implementation would do its best to carry recursions as far as possible. The only reason I can see for placing a limit on the stack size is that users become aware of trivially looping recursions more quickly. But this doesn't seem a particularly strong argument. Since I sometimes use non-tail-recursive functions on lists, I often start my OCaml code with the following line: Gc.set { (Gc.get()) with Gc.stack_limit = 16777216 };; (* Up the stack size *) so that my program doesn't die when occasionally dealing with longish lists, while being simple and efficient for the common case of short ones. Of course, if this balance were different, I might use another data structure and/or alternative algorithms. John. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners