Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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





      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