Email list hosting service & mailing list manager

Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx (08 Sep 2015 21:43 UTC)
Re: Don't be irritated by silly mistakes in draft #1 John Cowan (09 Sep 2015 01:10 UTC)
Re: Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx (09 Sep 2015 14:19 UTC)
Re: Don't be irritated by silly mistakes in draft #1 John Cowan (09 Sep 2015 15:26 UTC)
Re: Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx (09 Sep 2015 16:28 UTC)
Re: Don't be irritated by silly mistakes in draft #1 John Cowan (14 Sep 2015 02:02 UTC)

Re: Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx 09 Sep 2015 16:27 UTC

John Cowan <xxxxxx@mercury.ccil.org> writes:

>> > Ephemerons are inherently key-weak: I don't think it makes sense to have
>> > ephemeral-value or ephemeral-value-and-key.  So just use ephemeral-key
>> > (which could be shortened to ephemeral) and explain that ephemeral tables
>> > can be used in place of key-weak ones if the implementation sees fit.
>>
>> See MIT/GNU Scheme.  An ephemeral-value table simply swaps the position
>> of the key/value in the ephemerons held by the table (but the key is
>> still the key for the hash table).  In key & value, there is a pair of
>> ephemerons.
>
> The former makes sense operationally if not in human terms (what is it for?).
> The latter is just confusing.  I'll look at the MIT Scheme docs.

Ephemerons are incredibly confusing.  See my new prose explaining their
semantics as part of the ephemeral hashtables specification.  (Live
versions of my SRFI are now in my fork of the upstream repo, on GitHub.)

First of all, ephemerons hold both their members weakly.  I.e. you can
have as many ephemerons as you like, holding a bunch of keys and values
which all cyclically refer to each other, and all of them can be
deallocated if none of the keys and values are referred to from outside
the ephemeron graph.  There are absolutely no "strong" references in
ephemerons in the usual sense of strong references.

And yet, the datum member is kept alive so long as the key member is, as
if there were a strong reference to it.

By the way, I avoid calling the members key and value in my prose,
because they are confused with the key and value in a hashtable entry.
Orthogonal concepts, in truth.

This means that an ephemeral-key-and-value hashtable, which uses a pair
of ephemerons --one with key/value, the other value/key-- will release
an entry if and only if both the key and value have no references left
to them from outside the hashtable.  Otherwise one live object (key or
value) will keep the other alive (value or key) thanks to one or the
other ephemeron.

If an ephemeron simply held its datum strongly, that wouldn't work.
Having a pair of ephemerons with the key/value and value/key would
simply mean both the key and value are held strongly, one by one
ephemeron and the other by the other.  That was the case in my old
prose.  From what I can tell, SRFI-124's prose isn't exactly accurate
either.  If mine is accurate now, you can adopt/adapt it to yours maybe.

Fun-fact: GNU Emacs supports "key-and-value" as one of the hashtable
weakness options, which implements the semantics of double-ephemeron aka
ephemeral-key-and-value hashtables.  It supports "key-or-value" weakness
to mean the entry should be removed if either the key or value are
deallocated, which is what you get from plain weak-key-and-value
hashtables.  I don't know if the "key" and "value" options implement
correct behavior (use ephemerons instead of plain weakness; see below),
but they got the API right.  In Emacs Lisp, of all things!

And when it comes to ephemeral-key and ephemeral-value hashtables, their
effective behavior is simply what you would really expect from weak-key
and weak-value hashtables.  When there's no reference from the value to
the key of an ephemeral-key hashtable entry, the behavior is as if the
datum were held strongly; it will be kept alive, until the entry is
dropped because the key has been deallocated.  If the value refers to
the key however, then the fact that both are actually held weakly shines
and they are deallocated if no references to either is left from outside
the hashtable.  (So to answer your first question, ephemeral-value
hashtables are useful as the correctly-behaving (if slower) alternative
to weak-value hashtables.)

So while the simplistic way to view ephemerons is that they hold the key
weakly and block references from the (strongly held) datum to the key,
the accurate description is that both are held weakly, but the key holds
the value alive nevertheless for its own lifetime.

That was mentally exhausting for me to grok.  I hope this email will
save a couple people from that exhaustion!

Taylan