Re: either-guard reference implementation Marc Nieper-Wißkirchen 17 Jul 2020 13:50 UTC

Am Fr., 17. Juli 2020 um 15:40 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> The "change" was actually made a while ago, in 851ae058 (2020-07-03);
> my pull request yesterday was just a patch to bring the implementation
> into line with what the spec says.  It's unfortunate that we didn't
> get a chance to debate this change in semantics at the time.  However,
> I think that changing the SRFI to make maybe-let*, etc. compatible
> with SRFI 2 again would be too much of a change at this late date.

If you ask me, the SRFI was finalized a bit too early exactly because
of such points. (The error handling, which is contrary to the spirit
of R7RS-small, is another thing.) Given that most SRFIs are voted
unchanged into R7RS-large, we really should spend more time on
polishing individual SRFIs and develop many SRFIs in parallel. The
SRFI process (with its time constraints) may not be exactly the right
process for this, but I fear that R7RS-large will in the end be just a
large ball no better than C++.

> I don't particularly like the empty-body forms of and-let*, and I'm
> happy with how much simpler maybe-let* and friends are now with
> those forms eliminated.

"and-let*" would deserve its name without the empty body. And not
allowing the empty body only makes things more complicated in those
use cases where you actually want an empty body.