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