Browse thread
Objective Caml release 3.08.2
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Frédéric_Gava <frederic.gava@w...> |
| Subject: | Re: [Caml-list] Objective Caml release 3.08.2 |
> > 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