Cleanup Consent Ballot 1 concluded (preliminary announcement)
71 views
Skip to first unread message
Daphne Preston-Kendal
Jan 31, 2023, 5:31:22 AM1/31/23
to scheme-re...@googlegroups.com
Hello all,
This is a (somewhat belated) announcement that all proposals in the first Cleanup Consent Ballot have been adopted, because no objection was raised in the time period up to 1 January.
That means all the proposed fixes here:
https://codeberg.org/scheme/r7rs/wiki/Cleanup-Consent-Docket-1
are now part of the relevant Large language libraries.
Note that this does not affect the underlying SRFI libraries: that is, (in this case), the libraries called e.g. (srfi 101) or (srfi 113) are not affected by the changes; this effectively forks the versions in (scheme rlist) and (scheme set). Since the changes are backwards compatible in this case, this is more relevant in theory than in practice, but note that it would be wrong for the (srfi 113) versions of set-map and set-unfold to issue warnings about the old argument order even if they do support the new one too.
I had hoped — indeed, I still hope — to produce a document outlining the adopted changes to the SRFI libraries as well as patches to the sample implementations. Unfortunately, the first two weeks of the new year I came down quite sick indeed (and am still struggling with the after-effects to some extent); since then, catching up with other work which I couldn’t do while sick has taken so much time that I haven’t been able to contribute very much to Scheme-ing this month. (Indeed, I’m writing this email to ‘productively procrastinate’ finishing another paper.) Nonetheless, updated spec documents and sample implementations for the affected libraries will follow, and I will announce them here.
Daphne
This is a (somewhat belated) announcement that all proposals in the first Cleanup Consent Ballot have been adopted, because no objection was raised in the time period up to 1 January.
That means all the proposed fixes here:
https://codeberg.org/scheme/r7rs/wiki/Cleanup-Consent-Docket-1
are now part of the relevant Large language libraries.
Note that this does not affect the underlying SRFI libraries: that is, (in this case), the libraries called e.g. (srfi 101) or (srfi 113) are not affected by the changes; this effectively forks the versions in (scheme rlist) and (scheme set). Since the changes are backwards compatible in this case, this is more relevant in theory than in practice, but note that it would be wrong for the (srfi 113) versions of set-map and set-unfold to issue warnings about the old argument order even if they do support the new one too.
I had hoped — indeed, I still hope — to produce a document outlining the adopted changes to the SRFI libraries as well as patches to the sample implementations. Unfortunately, the first two weeks of the new year I came down quite sick indeed (and am still struggling with the after-effects to some extent); since then, catching up with other work which I couldn’t do while sick has taken so much time that I haven’t been able to contribute very much to Scheme-ing this month. (Indeed, I’m writing this email to ‘productively procrastinate’ finishing another paper.) Nonetheless, updated spec documents and sample implementations for the affected libraries will follow, and I will announce them here.
Daphne
John Cowan
Jan 31, 2023, 3:55:41 PM1/31/23
to scheme-re...@googlegroups.com
I thought I had mentioned that in the bytevector library, bytevector-copy! should be renamed to r6rs:bytevector-copy! (the Larceny solution). Obviously removing it is sufficient, but I think the next consent ballot should bring it back renamed. What do you think?
--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/4C9343B2-17D6-4B8F-B14D-11E28625EB4E%40nonceword.org.
Marc Nieper-Wißkirchen
Jan 31, 2023, 4:44:12 PM1/31/23
to scheme-re...@googlegroups.com
Am Di., 31. Jan. 2023 um 21:55 Uhr schrieb John Cowan <co...@ccil.org>:
>
> I thought I had mentioned that in the bytevector library, bytevector-copy! should be renamed to r6rs:bytevector-copy! (the Larceny solution). Obviously removing it is sufficient, but I think the next consent ballot should bring it back renamed. What do you think?
It can also be delivered through the compatibility library (rnrs bytevectors).
>
> I thought I had mentioned that in the bytevector library, bytevector-copy! should be renamed to r6rs:bytevector-copy! (the Larceny solution). Obviously removing it is sufficient, but I think the next consent ballot should bring it back renamed. What do you think?
>
> On Tue, Jan 31, 2023 at 5:31 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
>>
>> Hello all,
>>
>> This is a (somewhat belated) announcement that all proposals in the first Cleanup Consent Ballot have been adopted, because no objection was raised in the time period up to 1 January.
>>
>> That means all the proposed fixes here:
>> https://codeberg.org/scheme/r7rs/wiki/Cleanup-Consent-Docket-1
>> are now part of the relevant Large language libraries.
>>
>> Note that this does not affect the underlying SRFI libraries: that is, (in this case), the libraries called e.g. (srfi 101) or (srfi 113) are not affected by the changes; this effectively forks the versions in (scheme rlist) and (scheme set). Since the changes are backwards compatible in this case, this is more relevant in theory than in practice, but note that it would be wrong for the (srfi 113) versions of set-map and set-unfold to issue warnings about the old argument order even if they do support the new one too.
>>
>> I had hoped — indeed, I still hope — to produce a document outlining the adopted changes to the SRFI libraries as well as patches to the sample implementations. Unfortunately, the first two weeks of the new year I came down quite sick indeed (and am still struggling with the after-effects to some extent); since then, catching up with other work which I couldn’t do while sick has taken so much time that I haven’t been able to contribute very much to Scheme-ing this month. (Indeed, I’m writing this email to ‘productively procrastinate’ finishing another paper.) Nonetheless, updated spec documents and sample implementations for the affected libraries will follow, and I will announce them here.
>>
>>
>> Daphne
>>
>> --
>> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/4C9343B2-17D6-4B8F-B14D-11E28625EB4E%40nonceword.org.
>
> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
Vincent Manis (he/him)
Jan 31, 2023, 6:24:43 PM1/31/23
to scheme-re...@googlegroups.com, Daphne Preston-Kendal
This is excellent news. I'm assuming that at present there is no role
for the Publications Committee, as these all appear to be changes to the
individual library documents. However, I assume that documents are on
the horizon, as these revised libraries are now ready for Committee B
and my committee to put together into the beginnings of a Draft Report.
I look forward to that process.
Also, best wishes to Daphne as she continues to recover.
-- vincent
for the Publications Committee, as these all appear to be changes to the
individual library documents. However, I assume that documents are on
the horizon, as these revised libraries are now ready for Committee B
and my committee to put together into the beginnings of a Draft Report.
I look forward to that process.
Also, best wishes to Daphne as she continues to recover.
-- vincent
Reply all
Reply to author
Forward
0 new messages