Suggestion: ephemeron-case Daphne Preston-Kendal (04 Feb 2025 10:08 UTC)
Re: Suggestion: ephemeron-case John Cowan (04 Feb 2025 11:35 UTC)
Re: Suggestion: ephemeron-case Vincent Manis (he/him) (04 Feb 2025 19:38 UTC)
Re: Suggestion: ephemeron-case Marc Nieper-Wißkirchen (05 Feb 2025 15:12 UTC)
Re: Suggestion: ephemeron-case Daphne Preston-Kendal (05 Feb 2025 15:30 UTC)
Re: Suggestion: ephemeron-case Marc Nieper-Wißkirchen (05 Feb 2025 18:04 UTC)
Re: Suggestion: ephemeron-case Daphne Preston-Kendal (05 Feb 2025 18:16 UTC)
(missing)
Fwd: Suggestion: ephemeron-case Marc Nieper-Wißkirchen (16 Mar 2025 13:19 UTC)

Re: Suggestion: ephemeron-case Daphne Preston-Kendal 05 Feb 2025 18:15 UTC

On 5 Feb 2025, at 19:03, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

>> I don’t see how this is the case. The implementation would somehow need to both inline the helper-proc (in order to do the re-ordering optimization you were worried about when you introduced the reference-barrier procedure) but also discard the reference-barriering nature of the mention of ‘key’. This seems very unlikely.
>
> It should be possible to prove the correctness of a program formally.
> For that, "very unlikely" is not enough.

It’s up to the compiler to do this correctly (or not), of course.

> That said, all semantics suggested so far have another problem, which
> I haven't mentioned yet: A reference barrier on the key in the
> unbroken case is useless. The GC can break an ephemeron if, under the
> assumption that it is broken, the key will not be kept alive.
>
> I am going to post a "real life" example soon (I am currently ill, and
> my brain is not fully working) so that we have some concrete code to
> test potential syntax against.

Okay, please do. I’m a bit confused by this. Get well soon!

Daphne