[R6RS] Ticket Status as of svn repository revision 1196:

dyb at cs.indiana.edu dyb at cs.indiana.edu
Thu Dec 14 15:12:17 EST 2006

As you know, we're supposed to publish our responses by *tomorrow*
(Friday).  There are several open issues and lots of votes still
to be recorded, but probably nothing we can't handle.  I've put
a summary below, which I believe to be current with repository revision
1196 at Thu Dec 14 15:11:32 EST 2006.


-------- Open issues --------

18: The response has been updated but commits us to a particular mechanism
    for handling script exit codes.  I thought we were planning to be

    I propose that the response be changed to say we might describe an
    exit code mechanism that handles both integer and string exit codes
    in a non-normative appendix.

28: This didn't make the Wednesday agenda list.  The short description is:

    {real,rational,integer}-valued procedures need a rationale.

    There is a draft response but no one has voted for it yet.

    I propose that we accept the response as drafted.

73: This still needs to be decided.

    This was inaccurately recorded in Wednesday's agenda as lacking
    agreement only from Anton and Will; in fact, no one has voted yet.

    The current response does not reflect any agreement we've made so
    far.  Indeed, it appears as if we are agreeing to require uids to be
    library names and to drop generative record types, both of which
    I'm sure we do not want.

    I propose that we adopt the following response:

      The next draft report will suggest a convention (not requirement)
      that users construct UIDs either from library and record-type names
      or from names constructed using the UUID namespace.

80: This still needs to be decided

    I propose the following response:

        The set of procedures provided is not inconsistent: we have
        call-with-string-output-port and call-with-bytes-output-port
        because each returns a useful value (the string or bytes object);
        for the others mentioned in the comment's first two bullet points,
        call-with-port suffices; the simple-io is intended to be
        compatible with R5RS and, well, simpler.

        Where the procedures are mentioned is an editorial decision.
        We appreciate your suggestions and will take them into

129: We have agreement to accept the formal comment, but still need to
     decide on the syntax:

       Option 1: (nongenerative #t) 
         - with (nongenerative #f) or the absense of a nongenerative clause
           implying generative

       Option 2: (nongenerative)
         - with the absense of a nongenerative clause implying generative

     I propose option 2.

     For consistency with Option 2, I think we also need to replace
     (sealed #t) and (opaque #t) with (sealed) and (opaque), but Mike
     disagrees, so I am not proposing those changes.  Someone can always
     put forth a formal comment to this effect later.

-------- Tickets still to be updated (by whom) --------

7 (Will):
  - update ticket 7 response: no lazy; delay and force => (r6rs r5rs);
    flush (r6rs promises)

59 (Will):
  - update ticket 59 response to reflect decision not to allow
    #<n>(...) syntax

117: response not yet updated

122 (Will):
  - update ticket 122 response: next draft will not include
    real->single, real->double but; point out use of bytes objects
    to achieve the same effect

-------- Including above, tickets requiring agreement (by whom) --------

6   (Will)
7   (see above)
10  (Mike)
18  (see above)
23  (Anton)
25  (Will)
26  (Will, Matthew, Mike, Anton)
28  (see above)
35  (Will, Matthew, Anton)
36  (Will, Matthew, Mike, Anton)
39  (Will)
41  (Will, Matthew, Anton)
42  (Will, Matthew, Anton)
45  (Will, Matthew, Anton)
46  (Will, Anton)
48  (Will, Matthew, Anton)
51  (Will)
54  (Anton)
59  (see above)
61  (Will, Anton)
62  (Will, Anton)
68  (Will, Anton)
69  (Will, Matthew, Anton)
73  (see above)
75  (Will, Anton)
76  (Will, Matthew, Anton)
78  (Will)
79  (Will)
80  (see above)
86  (Will, Anton)
87  (Will, Matthew, Anton)
88  (Will, Matthew, Anton)
89  (Will, Anton)
90  (Will, Matthew, Anton)
92  (Will, Anton)           ; currently A? per Matthew
96  (Will, Anton)
97  (Will)
98  (Anton)
99  (Will, Matthew, Anton)
106 (Will)
107 (Anton)
108 (Will, Mike, Anton)
109 (Will, Anton)
111 (Will, Matthew, Anton)
113 (Will)
114 (Will, Matthew, Anton)
115 (Will, Matthew, Anton)
117 (see above)
118 (Will, Matthew, Anton)
120 (Anton)
122 (see above)
124 (Will, Matthew, Anton)
127 (Will)
129 (see above)
131 (Will)
132 (Will, Matthew, Anton)
136 (Will)

-------- No response for 12/15 --------

135, 137 and later

More information about the R6RS mailing list