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 KAA01647; Mon, 3 Feb 2003 10:26:17 +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 KAA28902 for caml-list@pauillac.inria.fr; Mon, 3 Feb 2003 10:26:16 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA04969 for ; Fri, 31 Jan 2003 23:27:53 +0100 (MET) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h0VMRpP00735 for ; Fri, 31 Jan 2003 23:27:52 +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 h0VMQ0t19358 for ; Fri, 31 Jan 2003 22:26:00 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 h0VMOZt13216 for ; Fri, 31 Jan 2003 22:24:35 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 M2003013114280802928 ; Fri, 31 Jan 2003 14:28:08 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1AW0DCGP>; Fri, 31 Jan 2003 14:27:49 -0800 Message-ID: From: "Harrison, John R" To: "'Brian Hurt'" Cc: caml-list@inria.fr, "Harrison, John R" Subject: RE: [Caml-list] @, List.append, and tail recursion Date: Fri, 31 Jan 2003 14:27:48 -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 | Actually, recursion seems to be very cheap- the recursive append function | is signifigantly faster than the reversing append, and almost as fast as | the set_cdr function. Yes indeed. This is why I think we shouldn't discourage people from using recursion by imposing arbitrary depth limits. | > 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. | | I like becoming aware of problems in my code as quickly as possible. It | lets me fix them quicker. Surely looping recursions aren't such a common problem that it really matters much? And one has other cues, like the excessive time taken by the evaluation. 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