From: EEK Cooper <s0567141@sms.ed.ac.uk>
To: Jean-Christophe Filliatre <filliatr@lri.fr>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Map.fold behavior changed
Date: Fri, 24 Feb 2006 13:29:50 +0000 [thread overview]
Message-ID: <20060224132950.7l49sm2akg0sskkw@www.sms.ed.ac.uk> (raw)
In-Reply-To: <17406.61821.450737.625981@gargle.gargle.HOWL>
I'm glad to hear that others are facing this problem as well. Those of
you who are: how are you dealing with it? Are you simply requiring your
users to use a particular version of the compiler? Or switching on
Sys.ocaml_version?
Quoting Jean-Christophe Filliatre <filliatr@lri.fr>:
> EEK Cooper writes:
>
> > My team just noticed that the behavior of Map.fold changed in OCaml
> > version 3.08.4.
> >
> > I'm concerned that the OCaml team would change the behavior of a
> > library function so late in its life. I understand that it was thought
> > to be "wrong" <http://caml.inria.fr/mantis/view.php?id=3607>, but
> > changing the behavior of an existing function breaks existing apps and
> > shouldn't be done lightly.
>
> I must agree with you since we also got a similar bug in one of our
> apps due to this Map.fold _implementation_ change.
>
> However, we must also admit that we were using an unspecified feature
> of the standard library. If I remember correctly, the documentation
> was saying that the traversal order was left _unspecified_.
For the record, I don't think this is true. My copy of map.mli, as part
of OCaml 3.08.3, says:
val fold: (key -> 'a -> 'b -> 'b) -> 'a t -> 'b -> 'b
(** [fold f m a] computes [(f kN dN ... (f k1 d1 a)...)],
where [k1 ... kN] are the keys of all bindings in [m]
(in increasing order), and [d1 ... dN] are the associated data. *)
specifying the same ordering as the current version. Also the original
bug ticket <http://caml.inria.fr/mantis/view.php?id=3607> about the
issue asserts that it should behave according to the documentation.
Since the behavior was NOT unspecified, it was reasonable to assume
that the documentation suffered from a simple typo, and to expect the
behavior not to change. I believe the documentation should have been
fixed rather than the behavior.
Ezra
next prev parent reply other threads:[~2006-02-24 13:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-24 11:22 EEK Cooper
2006-02-24 11:43 ` [Caml-list] " Jean-Christophe Filliatre
2006-02-24 13:29 ` EEK Cooper [this message]
2006-02-24 13:44 ` Jean-Christophe Filliatre
2006-02-24 14:13 ` Damien Doligez
2006-02-24 15:43 ` Brian Hurt
2006-02-24 16:20 ` Jean-Christophe Filliatre
2006-02-24 16:01 ` Joaquin Cuenca Abela
2006-02-27 12:59 ` Damien Doligez
2006-03-02 13:57 ` Ezra Cooper
2006-03-03 15:41 ` N. Owen Gunden
2006-03-09 7:14 ` Florian Hars
2006-03-13 16:31 ` Damien Doligez
2006-03-15 7:27 ` Florian Hars
2006-03-15 7:37 ` Jon Harrop
2006-03-15 7:40 ` Alain Frisch
2006-03-15 8:41 ` Florian Hars
2006-03-15 21:18 ` Christophe Raffalli
2006-02-24 15:31 ` Brian Hurt
2006-03-01 5:20 ` Nathaniel Gray
2006-03-01 9:33 ` Nicolas Pouillard
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=20060224132950.7l49sm2akg0sskkw@www.sms.ed.ac.uk \
--to=s0567141@sms.ed.ac.uk \
--cc=caml-list@yquem.inria.fr \
--cc=filliatr@lri.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