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)
|
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.