[R6RS] action items from today's call

[dyb at cs.indiana.edu]

Fellow editors,

We're closing in and may actually finish by the 15th, despite the enormity
of the task.  Thank you all for your efforts.

I've identified some action items from today's call below.  Most cover
responses to be added or updated.

Mike, if you have any questions about your action items, please let me
know.  You'll notice that I've asked you to respond to ticket 76, even
though it was assigned to Anton, because it appears from your exchange
with John Cowan that there might have been points of agreement, yet we're
not sure what they are.  (On the other hand, I've taken responsibility for
a couple of responses off of your hands.)

After the action items, I've also identified what I understand to be the
only remaining issues.  (Please correct me if I'm wrong.) We will try to
take care of these via email.

Anton, I gave you the formal-comment cleanup because you volunteered to
change "ticket #xxx" to "formal comment #xxx".  I'm willing to do the
cleanup instead; just let me know.

Kent

--------

Will:
  - update ticket 7 response: no lazy; delay and force => (r6rs r5rs);
    flush (r6rs promises)
  - update ticket 59 response to reflect decision not to allow
    #<n>(...) syntax
  - 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

Kent:
  - update responses for tickets 87, 26, 36, 41, 42, 48 to reflect
    Monday's decisions
  - update ticket 90 response to say next draft will contain rationale
    for why define-record-type can't be used to extend rtd created
    by make-record-type-descriptor (and to detail that rationale)
  - update 111, 114 responses to reflect decision not to add
    make-variable-transformer but to add identifier-syntax to base
    library and to export syntax-rules and identifier-syntax
    "for expand" from the r6rs base library
  - add response to ticket 115 identifying issues with possible solutions;
    no change for next draft; willing to entertain formal comment proposing
    comprehensive solution

Matthew:
  - propose response for ticket 46 (additional line terminators)
  - update ticket 86 response to reflect decision to require that
    library names be parenthesized but not require lib keyword
  - update ticket 109 response to say next draft will include
    negative meta levels

Mike:
  - update ticket 69 response: reject; remove mention of possibility
    that list must not contain #f or that implementation must raise
    an exception
    [FYI rationale for not mentioning these possibilities:  we don't need
    to mention these possibilities because they weren't in the formal
    comment or offered by formal commenter, and not saying anything allows
    someone like Andre to propose solution in the future]
  - add response to ticket 76 identifying points upon which Mike
    and Cowan agree, if any
  - add response to ticket 99 to the effect that we will rename
    "bytes" to some non-plural, non-hyphenated name with the actual name
    to be decided later
  - add ticket 118 response to the effect that next draft will keep
    status quo but we are continuing to discuss the issue and welcome
    additional suggestions and commentary
  - update ticket 124 response to say next draft will include
    file-exists? and delete-file, leaving comment about the other
    issue raised
  - add ticket 132 response agreeing to abbreviated syntax but with
    default being that fields are immutable

Anton:
  - add ticket 18 response: mention of exit codes will be eliminated with
    switch from script to program; may reappear in non-normative appendix
  - add ticket 68 response: Agreed
  - reword ticket 78 description of vector-map and vector-for-each to
    eliminate suggestion that they have same (list) interface as map and
    for-each
  - clean up formal responses:
    - replace "ticket #XXX" with "formal comment #XXX"
    - replace "DRAFT RESPONSE", "RESPONE", "RECOMMENDATION", etc.,
      consistently with "RESPONSE:"
    - replace "in a future draft" with "in the next draft" consistently
    - remove trac info like "Ticket #XXX (classification)" 
      and "Assigned to:" and "priority" (but not reported by,
      component, version) from formal response headers
  - set up for publication of responses, presumably to occur
    sometime on Friday

Remaining open issues:

  ticket 46: additional line terminators
    - pending Matthew's draft response

  ticket 76: proposed make-transcoder changes
    - pending Mike's draft response

  ticket 80: fix i/o interface inconsistencies
    - possibile 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;
        thanks for the suggestions
    - or we could make the requested additions and flush call-with-port,
      but then we wouldn't have call-with-port for ports created from
      arbitrary input sources and output sinks
    - orthogonal naming issue:
      - should we rename
          call-with-string-output-port => call-with-output-string
          call-with-bytes-output-port => call-with-output-bytes
        for consistency with the simple-i/o
        call-with-input-file and call-with-output-file?

  ticket 129: allow (nongenerative #t) perhaps with (nongenerative) syntax
    - straw poll of Will, Kent, Anton yielded 3 in favor after Matthew
      had withdrawn from call
    - Mike is also in favor
    - issue: should syntax be (nongenerative #t) or (nongenerative)?
    - if (nongenerative #t) should we allow (nongenerative #f)?
    - if (nongenerative) should we change (opaque #t) to (opaque) and
      (sealed #t) to (sealed)?