Taylor R Campbell <campbell+srfi-124@mumble.net> schrieb am Sa., 27. Aug. 2016 um 20:30 Uhr:

Date: Sat, 27 Aug 2016 15:40:16 +0000
From: Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>

> It's optional because it has to do something that in a non-trivial
> implementation of ephemerons, such as Racket's, can't always be done. If
> you need reference barriers, your code willl not be portable to all
> R7RS-large implementations, which is a pity, but there it is.

Is it a hard fact that it may be non-trivial to implement
`reference-barrier' for a given proper implementation of ephemerons?

Here's an implementation of reference-barrier that will almost
certainly have the desired immediate effect in any implementation,
though it may leak space.

(define last-reference 0)
(define (reference-barrier x)
(let ((y last-reference))
(set! last-reference x)
y))

I have a hard time believing that there are any Scheme systems out
there in which it is actually difficult to implement reference-barrier
correctly. It should be reliable included.

This is what I have been thinking. For Scheme systems that do not optimise a lot and do not re-order expressions and which do not collect GC locations before they go out of lexical scope formally, `reference-barrier' can be a no-op.

For optimizing Scheme compilers, `(reference-barrier <key>)` will have to be a primitive, which the compiler perceives as something not side-effect free and which behaviour seems to depend on all bits of the object `key'. In the final code that is run, the primitive again is a no-op.

I don't see any difficulties in implementing this.

On the other hand, how do you want to code safely without
`reference-barrier'?

Can't.

Thus, SRFI 124 desperately needs an erratum.

Marc