Le Fri, 31 Oct 2025 08:35:09 +0100,
Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit :

> Hi José,
>
> Thank you for reading SRFI 254 and giving feedback.
>
> One difference between SRFI 124 and SRFI 254 is that SRFI 124
> describes ephemerons and the situations in which they can be broken
> informally and with language that does not directly apply to the
> semantic model of Scheme as described in the reports and also in Will
> Clinger's paper on proper tail calls, which they cite. SRFI 254
> strives for semantics that are also correct in a formal sense, which
> is important both for implementers and users in cases of doubt.
> Naturally, the language of SRFI 254 must be more technical.
>
> Can you pin down more precisely which concept is hard to grasp for
> you so that I can possibly amend the paragraphs you cited?

Hi Mark,

Here is the first paragraph I pointed out:

> > If the content of an ephemeron's key field denotes a location or a
> > sequence of locations, the ephemeron is broken in the course of the
> > computation if the garbage collector would reclaim the location or
> > sequence of locations ...

That first part is clear. Nevertheless, I had formulated it in direct
style: "The ephemeron is broken if the garbage collector would reclaim
the location or sequence of locations associated to the key field." but
frankly it is not of importance.

> >                   ... if the location denoted by the ephemeron's
> > value field were weakly holding.

Here I'm lost. Isn't it the intent to have weak references in the value
field? So what is expected? Does it mean that the ephemeron is not
broken if the location (or sequence of locations) denoted by the value
field is alive by some other piece of the future computation? Well does
it care for ephemeron?

> >                                  The ephemeron may be broken in the
> > course of a computation if the Scheme implementation can prove that
> > the location or sequence of locations will not be kept alive in the
> > future of the computation if the ephemeron is broken.

Rereading is strange: "The ephemeron may be broken .... if the
ephemeron is broken." Ouch?! But which location (or sequence of
locations)? The key? The value? The both? Saturn? Jupiter? I find that
this second sentence does not help to understand. Either remove it or
reword it in a way that can be understood by simple minds.

Here is the second paragraph I pointed out:

> > If obj is an object such as a pair, string, vector, or bytevector
> > that denotes a location or a sequence of locations, the location or
> > the sequence of locations is kept alive.

Maybe you forgot to list records. No? However, what I understand is
that it is related to object being associated to a location (numbers
can be such object in some implementations). So maybe the list is not
needed.

Then it does not describes what is really done by reference-barrier:
ensuring that the location (or sequence of locations) denoted by obj
will never be reclaimed until reference-barrier is called. It implies
that compilers are not allowed to move expressions or commands across
it.

I was surprised to read all along "location or sequence of locations". I
still don't know exactly what is behind "sequence of locations".
vectors? arrays?

regards
José

>
> Thanks,
>
> Marc
>
> Am Fr., 31. Okt. 2025 um 08:16 Uhr schrieb jobol <xxxxxx@nonadev.net>:
>
> > Hi Marc, hi list,
> >
> > I read in srfi-254, about ephemeron:
> > ------
> > If the content of an ephemeron's key field denotes a location or a
> > sequence of locations, the ephemeron is broken in the course of the
> > computation if the garbage collector would reclaim the location or
> > sequence of locations if the location denoted by the ephemeron's
> > value field were weakly holding. The ephemeron may be broken in the
> > course of a computation if the Scheme implementation can prove that
> > the location or sequence of locations will not be kept alive in the
> > future of the computation if the ephemeron is broken.
> > -----
> >
> > I also read, about reference-barrier:
> > -----
> > If obj is an object such as a pair, string, vector, or bytevector
> > that denotes a location or a sequence of locations, the location or
> > the sequence of locations is kept alive.
> > -----
> >
> > In both case, I don't understand what describes and expects
> > srfi-254. But I cant easily understand what srfi-124 describes and
> > expects.
> >
> > So in my opinion if srfi-254 has to superseed srfi-124, some
> > rewording must occur.
> >
> > I didn't checked for srfi-246.
> >
> > regards
> > José
> >
> >