From: Vincent Poirriez <Vincent.Poirriez@univ-valenciennes.fr>
To: caml-list@inria.fr
Cc: Jean-Christophe.Filliatre@lri.fr, Xavier Leroy <Xavier.Leroy@inria.fr>
Subject: Re: module Set
Date: Mon, 20 Oct 1997 08:04:14 +0000 [thread overview]
Message-ID: <344B107E.BC7@univ-valenciennes.fr> (raw)
In-Reply-To: <199710170908.LAA29437@pauillac.inria.fr>
>
> > I would like to know why, in the module Set, it is written that the
> > order of the elements returned by the function "elements" is not
> > specified, whereas the elements are actually sorted (it is a prefix
> > traversal of a binary search tree).
>
> Abstract data types have a specification and an implementation.
> The specification usually does not specify everything about the
> behavior of the implementation, if only to allow the implementation to
> change later without breaking user's code.
I agree with this
>
> In the case of Set, the ordering property you see is a consequence of
> the implementation of sets as search trees. But other implementations
> (e.g. using hashing) would break that property.
It seems to be an other reason of this property in the current
implementation.
The module Set does implement sets over "ordered" types. Which should
not
be the case in an hashtable based implementation I guess. To have an
implementation over ordered type with no specified ordered-fold function
can
be frustrating...
>
> > I would like to use this property ; can't you give us this property in
> > the module Set for the next release ?
>
> I'd rather not. What you're looking for is not sets, but sets with
> some extra ordering properties. Don't use the generic Set package, then.
> Use your own Ordered_set package. (Feel free to cut and paste from
> set.ml to implement it, of course.) Well-defined abstract interfaces
> are more important that code sharing, in my opinion.
>
Why not provide three "new" functions : ordered_elements; ordered_fold
and
ordered_iter whith the same specification as the unordered ones except
that it should be precised that the elements are return or examined
using
the order Ord.compare. Of course, these functions should not be
necesseraly available in an hashatble based implementation.
Vincent Poirriez
--
Tel: (33) {0}3 27 14 13 33 Fax: (33) {0}3 27 14 12 94
mailto:Vincent.Poirriez@univ-valenciennes.fr
http://www.univ-valenciennes.fr/limav/poirriez
ISTV Université de Valenciennes Le Mont Houy BP 311 F59304 Valenciennes
CEDEX
prev parent reply other threads:[~1997-10-20 10:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-10-15 14:02 Jean-Christophe Filliatre
1997-10-17 9:08 ` Xavier Leroy
1997-10-17 13:46 ` Jean-Christophe Filliatre
1997-10-17 15:18 ` Judicael Courant
1997-10-17 15:38 ` Stefan Monnier
1997-10-20 8:04 ` Vincent Poirriez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=344B107E.BC7@univ-valenciennes.fr \
--to=vincent.poirriez@univ-valenciennes.fr \
--cc=Jean-Christophe.Filliatre@lri.fr \
--cc=Xavier.Leroy@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox