either-guard reference implementation Shiro Kawai (16 Jul 2020 02:15 UTC)
Re: either-guard reference implementation John Cowan (16 Jul 2020 04:28 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 04:42 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 05:01 UTC)
Re: either-guard reference implementation John Cowan (16 Jul 2020 15:12 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 17:24 UTC)
Re: either-guard reference implementation John Cowan (16 Jul 2020 17:45 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 18:04 UTC)
Re: either-guard reference implementation John Cowan (16 Jul 2020 18:07 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 18:29 UTC)
Re: either-guard reference implementation John Cowan (16 Jul 2020 23:31 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (17 Jul 2020 00:10 UTC)
Re: either-guard reference implementation Arthur A. Gleckler (17 Jul 2020 03:15 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (17 Jul 2020 04:27 UTC)
Re: either-guard reference implementation Arthur A. Gleckler (17 Jul 2020 05:00 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (17 Jul 2020 05:55 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (17 Jul 2020 05:55 UTC)
Re: either-guard reference implementation Shiro Kawai (17 Jul 2020 07:35 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (17 Jul 2020 13:40 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (17 Jul 2020 13:50 UTC)
Re: either-guard reference implementation Arthur A. Gleckler (18 Jul 2020 05:22 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (18 Jul 2020 12:32 UTC)
Re: either-guard reference implementation John Cowan (29 Jul 2020 23:18 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (31 Jul 2020 08:36 UTC)
Re: either-guard reference implementation John Cowan (05 Aug 2020 06:07 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (05 Aug 2020 06:22 UTC)
Re: either-guard reference implementation John Cowan (05 Aug 2020 06:28 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (05 Aug 2020 06:48 UTC)
Re: either-guard reference implementation John Cowan (07 Aug 2020 22:08 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (09 Aug 2020 11:14 UTC)
Re: either-guard reference implementation John Cowan (09 Aug 2020 13:10 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (11 Aug 2020 08:14 UTC)
Re: either-guard reference implementation John Cowan (11 Aug 2020 16:48 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (15 Aug 2020 12:11 UTC)
Re: either-guard reference implementation John Cowan (15 Aug 2020 13:57 UTC)
Re: either-guard reference implementation Marc Nieper-Wißkirchen (16 Jul 2020 20:40 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 23:25 UTC)

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.