On 9 Oct 2025, at 15:24, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

> Thank you for the example code. Unfortunately, the suggested
> definition of "ephemeron-case" is useless.

I’d like to take this conversation in a slightly different direction.

Can you offer any demonstration at all – from any real language runtime you can think of, Scheme or non-Scheme – that reference-barrier is actually needed; that compilers without it would break things in the way you say they could when dereferencing weak pointers; that compilers which would do the ‘optimization’ you invented reference-barrier to productively frustrate would not be completely broken by design?

I cannot find any.

Chez Scheme added keep-live in version 10, but it had ephemerons and other weak references long before. Its documentation suggests the purpose of keep-live is related to the ‘immobile objects’ feature, not to the re-ordering optimization you are concerned about.

MIT Scheme seems to have added reference-barrier purely because of SRFI 124. It also had ephemerons and weak pairs before. Riastradh suggested reference-barrier: his rationale appears to have been entirely different, to do with an implementation where broken ephemerons were replaced by #f. <https://srfi-email.schemers.org/srfi-124/msg/2905901/>

Outside of the Scheme world, I am unable to find any language or implementation of any language which has anything like reference-barrier. JavaScript’s ephemeron tables (WeakMap) and weak sets (WeakSet) and weak boxes (WeakRef) all have no such concept. OCaml, in runtime semantics a close match to Scheme, doesn’t have it. <https://ocaml.org/manual/5.3/api/Ephemeron.html> Even Haskell, which due to its lazy evaluation is extremely reordering-happy in its implementation, does not appear to have an equivalent of the reference-barrier. <https://hackage.haskell.org/package/base-4.21.0.0/docs/System-Mem-Weak.html>

I haven’t surveyed Scheme implementers (well, except Alex Shinn who made his feelings known well enough when it came up in another context), but I suspect this whole idea of yours is premature pessimization. Compilers are quite intelligent enough to realize that ephemeron-key and ephemeron-datum themselves are procedures that can’t safely be re-ordered around – and this is not a ‘sufficiently smart compiler’ argument, because a truly dumb compiler wouldn’t have an issue here either, since the problem is that you’re arguing a compiler might attempt to be smart but do something wrong. In reality, a compiler which tries to be smart in that way would simply be broken, and the way it would be broken would be the same as if it allowed re-ordering set! or write or any other side-effectual procedure so the side-effects happen in the wrong order. They already have mechanisms that tell them they can’t do that, and if they can apply those mechanisms to reference-barrier, they can just as well apply them to the actual source of the reference instead.

[Not speaking as chair but as an individual WG2 member:] If reference-barrier stays in the SRFI up to finalization and thus remains a candidate for R7RS large, I will want a comprehensive survey of implementers on this question before we clutter the Scheme report with it.

Best wishes

Daphne