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 <email@example.com>: > 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.