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)

Suggestion: ephemeron-case Daphne Preston-Kendal 04 Feb 2025 10:07 UTC

We’ve talked elsewhere about convenience syntax for this before, but I think I now have worked out reasonable syntax for it.

SRFI 254 should add syntax called ephemeron-case:

(ephemeron-case <<expression>>
  ((<<key identifier>> . <<value identifier>>)
   <<body>>)
  (else <<body>>))

Semantics:

The <<expression>> is evaluated to produce an ephemeron.

If the ephemeron is live, the first <<body>> is evaluated with the identifiers <<key identifier>> and <<value identifier>> in scope. The <<key identifier>> is bound as if to identifier syntax which both returns the key of the ephemeron and ensures that it is kept live, as if by the reference-barrier procedure. It is a syntax violation to use set! on the <<key identifier>>. The <<value identifier>> is bound as a variable to the value of the ephemeron.

If the ephemeron is broken, the second <<body>> is evaluated with no additional identifiers in scope.

The advantage is that with convenience syntax available which automatically does all the right things, people will be less tempted to do broken things like first checking the liveness of an ephemeron before pulling out the key and value, or forgetting to use reference-barrier.

Daphne