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 UAA30898; Mon, 27 May 2002 20:16:48 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 UAA30886 for ; Mon, 27 May 2002 20:16:47 +0200 (MET DST) Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4RIGiD07459; Mon, 27 May 2002 20:16:44 +0200 (MET DST) Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g4RIGgZr000335; Tue, 28 May 2002 04:16:42 +1000 (EST) Received: from ozemail.com.au (ppp178.dyn146.pacific.net.au [210.23.146.178]) by wisma.pacific.net.au with ESMTP id EAA06988; Tue, 28 May 2002 04:16:39 +1000 (EST) Message-ID: <3CF277FD.8070407@ozemail.com.au> Date: Tue, 28 May 2002 04:16:29 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Xavier Leroy CC: caml-list@inria.fr Subject: Re: [Caml-list] Hashtbl iter semantics References: <3CF102B3.7030200@ozemail.com.au> <20020527163853.A25103@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Xavier Leroy wrote: >>Could the ocaml team please clarify the semantics of Hashtbl.iter? >>In particular, can I use Hashtbl.replace during iteration? >>[What about add, removed, etc?] >> > >You can use Hashtbl.{replace,add,remove} while iterating over the same >hash table, in the sense that it will not corrupt the table. However, >there is no guarantee that the iteration will "see" the modification >or not. E.g. if you add an element, the function being iterated can >be called on the newly added element, or not, depending on the >relative positions of the new element and of the iteration point >inside the hash table. > >If you need stronger guarantees > No, I'd just like some text in the manual please, that I can use to reason about the correctness of my algorithms. For example, it isn't clear if I add a key, if the table might not be reorganised so that 50 keys from the table are never presented. The table isn't 'corrupted, though the scan pointer might be :-) I guess nothing of the sort will happen with Hashtbl.iter. For example: delete: if a binding is deleted it won't be presented subsequently. Add: the binding may or may not be presented. Replace: if the binding is presented, it will have the data value used in replace. If the binding was already presented, it will not be represented. Otherwise: the binding will be presented with its initial data value. -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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