Am Do., 6. Nov. 2025 um 20:27 Uhr schrieb jobol <xxxxxx@nonadev.net>:
>
> Le Thu, 6 Nov 2025 12:43:14 +0100,
> Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit :
>
> > Hi José,
> >
> > Thanks for the suggestion!
> >
> > If I understand correctly, one would use `ephemeron-get' as follows:
> >
> > (let-values (((key val) (ephemeron-get x)))
> > (if key
> > <code that can use VAL because the ephemeron was unbroken>
> > <code that handles the broken case and ignores VAL>))
>
> yes
>
> > Without `ephemeron-get', this would look like
> >
> > (let ((val (ephemeron-value x)))
> > (if (ephemeron-key x)
> > <code using VAL>
> > <code ignoring VAL>))
> >
> > If used in this way, it doesn't seem that `ephemeron-get' saves much
> > typing. Maybe, I misunderstood.
>
> I agree.
>
> My idea was that the operation ephemeron-get is "atomic". I'm not sure
> but in your definition of GC and weak reference, the collection might
> occur at anytime.
Indeed, a GC could happen between "ephemeron-value" and
"ephemeron-key" in the second code example. The result, however,
wouldn't be effectively different if the GC happened before
"ephemeron-value" in the second code example or "ephemeron-get" in the
first code example. In other words, atomicity with respect to GC as in
"ephemeron-get" doesn't buy anything.
> Then, in your example without ephemeron-get, it may
> occur between ephemeron-value and ephemeron-key and give a different
> result. That is very theorical I'm admitting.
>
> The other point is that I'm agreeing that reference-barrier is perhaps
> not needed and that use of might ephemeron-get make it real.
No, a procedure like "ephemeron-get" does not make "reference-barrier"
obsolete. You need at least one expression form that ensures that a
value is not garbage collected at least up to the point that the form
is evaluated.
In principle, such a form could just mean "variable reference where
the variable stores the value to be protected from GC". But this would
have a devastating effect on optimisability. Your procedure
"ephemeron-get" does not keep any value (to be more precise: any
location) alive. In any case, you do not want to keep a key stored in
an ephemeron alive, but some value that comes from somewhere else, and
that could be a key.
Marc