Thank you for your suggestions. Unfortunately, the `ephemeron-case` (or `ephemeron-if`) form violates the principle of macro design that syntax that looks like a variable reference should work like a variable reference; in particular, it should have no (observable) side effects. (The most substantial criticism raised against identifier syntax was that it would be possible to write macros violating this principle.)
Effectively, this means that `ephemeron-case` does not lead to error-free code. In the following example, referencing the `key` argument of the `helper-proc` will not maintain the reference barrier: (ephemeron-case eph ((key . value) (helper-proc key value)) (else 'broken)) Another problem is that `reference-barrier` may be a costly operation for the optimiser (because it forbids reordering of code); it may be too costly if the barrier is invoked after every reference of the key. Am Di., 4. Feb. 2025 um 20:38 Uhr schrieb Vincent Manis (he/him) <vma...@telus.net>: > > On 2025-02-04 03:34, John Cowan wrote: > > Hmm. Perhaps this should supersede the procedural interface rather than > supplementing it? > > On Tue, Feb 4, 2025, 5:08 AM Daphne Preston-Kendal <d...@nonceword.org> wrote: >> >> 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>>)) >> >> >> [ > > I'm with John on at least considering supersession, as I'm having difficulty > imagining a situation where this would be insufficient. If such a case can be > made, that's fine. Otherwise, I recommend withdrawing the procedural > interface, but using it in the specification of this form. > > At the risk of some bikeshedding, I'd suggest that this isn't really a case > form, but an if-then-else form, which might yield a syntax like this: > > (ephemeron-if <expression> (key value) <then-body> <else-body>) > > or are there multiple cases? Also, I've removed the dot from the bindings > argument, as that's more like the bindings in a let-form than like anything > else I can imagine. > > -- vincent
