Email list hosting service & mailing list manager

Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (20 Jun 2021 16:31 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (20 Jun 2021 16:40 UTC)
Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (20 Jun 2021 16:53 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (20 Jun 2021 17:43 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (20 Jun 2021 18:23 UTC)
Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (20 Jun 2021 18:42 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (20 Jun 2021 18:47 UTC)
Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (20 Jun 2021 18:53 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (20 Jun 2021 18:59 UTC)
Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (20 Jun 2021 19:13 UTC)
Re: Draft #11 deadline for feedback John Cowan (26 Jun 2021 11:18 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (26 Jun 2021 11:46 UTC)
Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (26 Jun 2021 16:46 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (26 Jun 2021 18:47 UTC)
Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe (26 Jun 2021 21:11 UTC)
Re: Draft #11 deadline for feedback John Cowan (26 Jun 2021 19:35 UTC)
Re: Draft #11 deadline for feedback Marc Nieper-Wißkirchen (26 Jun 2021 21:57 UTC)

Re: Draft #11 deadline for feedback Wolfgang Corcoran-Mathe 20 Jun 2021 18:42 UTC

On 2021-06-20 20:23 +0200, Marc Nieper-Wißkirchen wrote:
> PS There are some other references to the type "exact-integer" (not
> explained), which all should probably be updated to "fixnum".

The return types of fxmapping-count and fxmapping-size should indeed
be 'fixnum', and not 'exact-integer'.  The explanation of the other
occurrences of 'exact-integer' as a type is that I was preferring it
to 'fixnum' for the types of arguments to higher-order functions,
apparently in the name of generality.  I realize this was a mistake,
and again a result of confusing covariance and contravariance.

It's not exactly compelling, but I will fix it for consistency.

> PPS Unrelated to this but related to my ongoing discussion with Shiro: SRFI
> 224 is silent with respect to multiple returns from the higher-order
> procedures. Given that SRFI 224's objects are purely functional, the purist
> approach of full compatibility with call/cc makes sense (and which we also
> have with all R7RS base procedures).

Agreed on approach, but what changes would you suggest to make this
clear?

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

"Nothing can transcend its smallest elements." --CEO Nwabudike Morgan