|
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)
|
||
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) <xxxxxx@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 <xxxxxx@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
