From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id B272DBC2F for ; Thu, 25 Nov 2004 19:04:43 +0100 (CET) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iAPI4hL8016761 for ; Thu, 25 Nov 2004 19:04:43 +0100 Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf1001.wanadoo.fr (SMTP Server) with SMTP id 5310618000B1; Thu, 25 Nov 2004 19:04:43 +0100 (CET) Received: from nono (ARouen-106-1-35-177.w217-128.abo.wanadoo.fr [217.128.135.177]) by mwinf1001.wanadoo.fr (SMTP Server) with SMTP id E24A1180009D; Thu, 25 Nov 2004 19:04:42 +0100 (CET) Message-ID: <008001c4d319$693f0f40$b18780d9@mshome.net> From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Gava?= To: Cc: References: <75E02BC8-3EEA-11D9-A6E2-00039310CAE8@inria.fr> <004f01c4d2fd$b87d6140$b18780d9@mshome.net> <1101398012.9291.48.camel@pelican.wigram> Subject: Re: [Caml-list] Objective Caml release 3.08.2 Date: Thu, 25 Nov 2004 19:05:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Miltered: at nez-perce with ID 41A61EBB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; gava:01 gava:01 caml-list:01 associative:01 associative:01 elt:01 elt:01 iter:01 iter:01 bug:01 ric:98 deliberate:98 ric:98 abstract:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=2.2 required=5.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=disabled version=3.0.0 X-Spam-Level: ** > > Why an order for the fold operator ? > > Because Set.t is an ordered container, Ok, but it is an abstract type : you do not know (except when you used ocamlbrowser) how it works and you do not need it (you do not want to know how really work the Thread for example (simple user point of view) ). > and order matters for folds if the operator being folded > isn't associative. Ok. That's right. This is why I thinks, another fold is necessary for associative operators (and thus for possible optimizations of this fold) and thus wihtout side-effects. > These functions are deterministic and depend on order: > Set.min_elt, Set.max_elt, Set.elements, Set.fold, Set.iter Ok, for Set.iter but Set.elements could also give the elements of the set in any order: you need to specify to the SGBD that you want an ordered table in SQL, why here it is necessary. You can sort your list if you need (peraps it takes more time but two functions could be give to the users: Set.elements and Set.order_elements). A Set.elements without ordering the elements would be more efficient. > Set.choose, however, chooses at random, and Set.for_all > doesn't appear to be ordered either (is that a bug > in the doc or deliberate?) What would be the interest of sorting all the times the elements ? Frédéric Gava