Email list hosting service & mailing list manager

either-guard reference implementation Shiro Kawai (16 Jul 2020 02:14 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:41 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:11 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:06 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 18:28 UTC)
Re: either-guard reference implementation John Cowan (16 Jul 2020 23:30 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:14 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 04:59 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:31 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:35 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:13 UTC)
Re: either-guard reference implementation John Cowan (09 Aug 2020 13:09 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:39 UTC)
Re: either-guard reference implementation Wolfgang Corcoran-Mathe (16 Jul 2020 23:25 UTC)

Re: either-guard reference implementation Wolfgang Corcoran-Mathe 16 Jul 2020 04:41 UTC

On 2020-07-16 00:28 -0400, John Cowan wrote:
> FIxed in commit 60231ed826a7755ed9bdddb317c6f0f33e5637e7.
>
> On Wed, Jul 15, 2020 at 10:15 PM Shiro Kawai <xxxxxx@gmail.com> wrote:
>
> > There seems a disagreement between srfi text and reference implementation.
> >
> > The text says:
> >   (either-guard ( pred-expr ) . body)
> >
> > The reference implementation lacks parenthesis around pred-expr:
> >   (either-guard pred-expr expr1 expr2 ...)

There's still a disagreement; either-guard, as currently implemented,
doesn't allow <body> to be empty.  I think that this is correct, and
that the spec is in error, since it's unspecified what either-guard
returns if there are no body expressions.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Personally, I get a little tired of the argument: My worse-is-better
is better than your worse-is-better because I'm better at being
worser!" --Larry Wall