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 7B539BC48 for ; Fri, 18 Mar 2005 18:46:12 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2IHkCsW002551 for ; Fri, 18 Mar 2005 18:46:12 +0100 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 SAA05092 for ; Fri, 18 Mar 2005 18:46:11 +0100 (MET) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2IHk9UZ008057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Mar 2005 18:46:11 +0100 Received: (qmail 508 invoked from network); 18 Mar 2005 17:46:08 -0000 Received: from shell1.sea5.speakeasy.net ([69.17.116.2]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Mar 2005 17:46:07 -0000 Date: Fri, 18 Mar 2005 09:46:07 -0800 (PST) From: brogoff X-X-Sender: brogoff@shell1.sea5.speakeasy.net To: caml-list@inria.fr Subject: Re: [Caml-list] OCaml troll on Slashdot In-Reply-To: <87acp213ui.fsf@qrnik.zagroda> Message-ID: References: <20050316001819.GB347@first.in-berlin.de> <891bd33905031619484825e276@mail.gmail.com> <200503171016.18310.jon@ffconsultancy.com> <87acp213ui.fsf@qrnik.zagroda> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 423B13E4.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 423B13E1.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 stack:01 recursion:01 recursion:01 sml:01 gc'ed:01 heap:01 stack:01 bignums:01 wrote:01 overflows:01 stacks:01 extensible:01 extensible: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 Thu, 17 Mar 2005, Marcin 'Qrczak' Kowalczyk wrote: > It's not the fault of the mapping function but of the stack being > non-extensible. A user-written recursion can blow it too. Functional > programming is supposed to encourage recursion, and a non-tail-recursive > 'map' is much more readable than alternatives. Interesting approach. Do you have any information as to how big the performance hit is? I've never used SML/NJ except for a few toy programs, but I recall that it puts activation records on the Gc'ed heap (correct me if I'm wrong someone) so that call/cc is more efficient, so stack overflows shouldn't be a problem there either. Could you comment on why you chose extensible stacks rather than the SMLNJ approach for Kogut. > My implementation of my language Kogut has extensible stack. > And transparent bignums when appropriate. Yes, it's slower, > but correctness is more important. Hard to disagree when you put it that way, but there you seem to be posing a false dichotomy. With enough work, C code can be made safe. What I think you intend is that you'd rather it be easy to write safe code than that it be asy to write fast code, in the language. I wouldn't mind that, as long as it isn't ridiculously hard or impossible to do the latter in the language. -- Brian