From: Brian Hurt <bhurt@spnz.org>
To: Damien Doligez <damien.doligez@inria.fr>
Cc: caml-list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Map.fold behavior changed
Date: Fri, 24 Feb 2006 09:43:43 -0600 (CST) [thread overview]
Message-ID: <Pine.LNX.4.63.0602240934480.9569@localhost.localdomain> (raw)
In-Reply-To: <1AEDE2F4-2D83-416F-AFDC-7ECAF892BFBD@inria.fr>
On Fri, 24 Feb 2006, Damien Doligez wrote:
> On Feb 24, 2006, at 14:29, EEK Cooper wrote:
>
>> 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.
>
> "It is documented to do something else, so we will assume that it's intended
> to do what it does, instead of what the documentation says."
>
> I don't think this is very reasonable.
OK, My stupid question was already answered.
There are times, however, when a specified traversal ordering is required.
Since a map is defined as an ordered tree, having a fold_left and
fold_right functions would not be hard to do:
let rec fold_left f init = function
| Empty -> init
| Node(l, v, d, r, _) ->
fold_left f (f (fold_left f init l) v d) r
let rec fold_right f node init =
match node with
| Empty -> init
| Node(l, v, d, r, _) ->
fold_right f l (f v d (fold_right f r init))
These aren't checked to see if they even compile, but they're close.
I may take this opportunity to offer a red-black tree implementation of
Map as a replacement, if people are interested. The advantage a
red-black tree is that it uses one less word of memory per element in a
map.
Brian
next prev parent reply other threads:[~2006-02-24 15:43 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
2006-02-24 13:44 ` Jean-Christophe Filliatre
2006-02-24 14:13 ` Damien Doligez
2006-02-24 15:43 ` Brian Hurt [this message]
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=Pine.LNX.4.63.0602240934480.9569@localhost.localdomain \
--to=bhurt@spnz.org \
--cc=caml-list@yquem.inria.fr \
--cc=damien.doligez@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