From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr 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 68F55BB9C for ; Sun, 18 Sep 2005 16:28:24 +0200 (CEST) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j8IESNIf029426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 18 Sep 2005 16:28:24 +0200 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 9438120014 for ; Sun, 18 Sep 2005 16:28:23 +0200 (CEST) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11085-01-37 for ; Sun, 18 Sep 2005 16:28:21 +0200 (CEST) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 79B6920010 for ; Sun, 18 Sep 2005 16:28:21 +0200 (CEST) Received: from eiger.cip.physik.uni-muenchen.de (eiger.cip.physik.uni-muenchen.de [141.84.136.54]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 07EA626F4D for ; Sun, 18 Sep 2005 16:28:21 +0200 (CEST) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id 00D5B12F75; Sun, 18 Sep 2005 16:28:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id F04AD12F17 for ; Sun, 18 Sep 2005 16:28:20 +0200 (CEST) Date: Sun, 18 Sep 2005 16:28:20 +0200 (CEST) From: Thomas Fischbacher To: caml-list@yquem.inria.fr Subject: OCaml Documentation Request Message-ID: X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at nez-perce with ID 432D7987.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 val:01 initialized:01 integers:01 regexp:01 rec:01 sould:01 cip:98 cip:98 lambda:01 lambda:01 exception:01 tail:01 matched:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_FAIL autolearn=disabled version=3.0.3 The Array.init and Array.make documentation says more or less the same: ====> << val init : int -> (int -> 'a) -> 'a array >> Array.init n f returns a fresh array of length n, with element number i initialized to the result of f i. In other terms, Array.init n f tabulates the results of f applied to the integers 0 to n-1. Raise Invalid_argument if n < 0 or n > Sys.max_array_length. If the return type of f is float, then the maximum size is only Sys.max_array_length / 2. <==== Question: Is the statement about array max lengths accurate for 64-bit systems as well? Request: The documentation does not mention the order in which the array is filled. Hence, the underlying implementation could do this last-to-first, first-to-last, or in some other crazy order. Of course, the presumably only reasonable way is to do it first-to-last, considering both cache prefetch and similar issues at the bare metal level, and the principle of least surprise. However, this is not a guaranteed property, so one cannot use this in conjunction with code where application order does matter, e.g.: let make_rx_decomposer nr_pieces rx_string = let rx = Str.regexp rx_string in fun str -> let rec walk so_far pos = let pos_found = try Str.search_forward rx str pos with | Not_found -> (-1) (* This is a hack to maintain the niceties of tail recursiveness (which exception handling would destroy) without consing an int option. *) in if pos_found=(-1) then List.rev so_far else let pos_end = Str.match_end() in let pieces_here = Array.init nr_pieces (fun n -> Str.matched_group n str) in walk (pieces_here::so_far) pos_end in walk [] 0 ;; As it stands, this technique is not valid, as it uses non-guaranteed properties - the code "seems to work" anyway, however. (But maybe, it sould be more appropriate to remove the implicit dependence on hidden state of some Str functions by providing a handle for such internal regexp-matcher state anyway.) What's the opinion of the list on this issue? -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)