caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Lindsay Errington <lindsay.errington@gmail.com>
To: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: [Caml-list] weak functional maps and ephemerons
Date: Thu, 20 Dec 2018 10:44:41 -0800	[thread overview]
Message-ID: <CAPeKkNjM6+vSy9_cn9aWsdOQuah-wC4V1Xb-esVkA6b8g08dOw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

As mentioned in my previous post, I'd like to have weak functional maps.
Keeping it simple, suppose the maps are implemented as binary search trees
of key/value pairs where pairs are wrapped in an ephemeron:

module Eph = Ephemeron.K1
type key = ... (* something boxed and ordered *)
type 'a bst =
  | Empty
  | Node of {left : 'a bst; pair : (key,'a) Eph.t; right : 'a bst}

Cheating a little with pattern matching, if {left; pair=(Some k, Some v);
right} is an entry in a tree and I subsequently drop all references to k,
then my understanding is that following gc, both options will become None.
If I then encounter that node when looking for some k', I'm forced to merge
the left and right subtrees before continuing.

The question is, why does gc clobber the key in the ephemeron? Why not
provide the key when the ephemeron is created and collect the key when the
ephemeron is collected? For the above use-case, it would mean that one
could still search the tree and defer cleaning up the bst until later.

Lindsay

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 1221 bytes --]

                 reply	other threads:[~2018-12-20 18:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAPeKkNjM6+vSy9_cn9aWsdOQuah-wC4V1Xb-esVkA6b8g08dOw@mail.gmail.com \
    --to=lindsay.errington@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).