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