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)
|
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