Ephemerons are the ‘right’ weak referencing primitive, but they’re also the most expensive for garbage collectors to implement. (SRFI 124 mentions that MIT Scheme needs five words of storage for an ephemeron vs only two for a weak pair.) A optimizing Scheme implementation will therefore probably ideally have multiple implementations of ephemerons, depending on what they can prove about the relationship between the value and the key.

For example, if the value is a type which can’t contain any pointers, such as an immediate or a string or a number, an implementation can just implement an ephemeron as a weak-strong pair, which is a lot cheaper to keep track of.

I suggest this be made explicit in the spec with a ‘should’ suggestion for what the value in an ephemeron should be set to when the ephemeron is being used only as a weak box for its key. (Probably #f.) This will allow portable code that takes advantage of multiple implementations’ fast paths for ephemerons used as weak boxes.

Daphne