[R6RS] action items from today's call

[Michael Sperber]

dyb at cs.indiana.edu writes:

>   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

That's essentially my position. See:

http://lists.r6rs.org/pipermail/r6rs-discuss/2006-November/001012.html

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

No.

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

I don't really care on this point by itself.  But ...

>     - if (nongenerative #t) should we allow (nongenerative #f)?

No.  This would imply that I prefer (nongenerative)

>     - if (nongenerative) should we change (opaque #t) to (opaque) and
>       (sealed #t) to (sealed)?

No.  We decided to make the reverse change sometime during the
drafting of SRFI 76.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla