R6RS Formal Comments & Responses

Round 2

Formal comments which were submitted between November 16th, 2006 and April 9th, 2007 are listed below. Each comment is numbered for reference purposes. Comments are linked to a text file containing the text of the comment, followed by a "RESPONSE:" heading, followed by the editors' formal response.

  • Comment #135: syntax-case specification - requests for minor modifications
  • Comment #137: Non-ASCII characters should not be treated all alike
  • Comment #138: The treatment of version number needs to be changed
  • Comment #139: The real->flonum procedure should be moved out of the base package
  • Comment #140: Max and min with zero arguments
  • Comment #141: It is not clear what negating 0.0 produces
  • Comment #142: Change the response to formal comment #47 to provide vector-sort!, not vector-sort.
  • Comment #143: Request for reconsideration of formal comment #11
  • Comment #144: The description of the naming convention for condition types is obviously incorrect
  • Comment #145: < is inconsistent on NaNs.
  • Comment #146: Mustard must not be preposterous
  • Comment #147: Nothing is said to be safe
  • Comment #148: String output ports are even more broken now
  • Comment #149: Clarification of chapter 1 overview bits re: exactness and complex numbers
  • Comment #150: The library form should prefix rather than enclose libraries
  • Comment #151: Relax ordering constraint on library bodies
  • Comment #152: Inappropriate number of values should be defined sensibly
  • Comment #153: Rename on export considered harmful
  • Comment #154: Datums should be self-evaluating generally
  • Comment #155: eq? and eqv? should apply to all standardized objects
  • Comment #156: Rename the unspecified value
  • Comment #157: Allow limited comparisons of complex numbers
  • Comment #158: Typo - 5.92 ("max" should be "may")
  • Comment #159: (r6rs base) must also export _ and ... at level 1
  • Comment #160: Invoking toplevel undefined
  • Comment #161: Problems in description of instantiation semantics
  • Comment #162: Error in Runge-Kutta example
  • Comment #163: Index missing _
  • Comment #164: Treatment of literal keywords
  • Comment #165: Rename named `let'
  • Comment #166: Make unspecified return values of eq? / eqv? unspecified
  • Comment #167: floor, ceiling, truncate, and round are unnecessarily over-specified on infinities and NaNs
  • Comment #168: argument names in library section 1.1: char vs. letter
  • Comment #169: confusion about which bytevectors exist
  • Comment #170: asymmetry between fold-left and fold-right
  • Comment #171: verbosity of "fields" specifications for records
  • Comment #172: "Whitespace and newlines" = whitespace
  • Comment #173: Section 1.5: (f 23) is 65, not 42
  • Comment #174: No defaults given for sealed and opaque
  • Comment #175: returning exception handlers easily trigger infinite loops
  • Comment #176: Raising of exceptions should not be ambiguous or confusing
  • Comment #177: C sharp can pass arguments by reference
  • Comment #178: should allow quoting non-letters in identifiers
  • Comment #179: Compound conditions considered bogus
  • Comment #180: Binary and string pseudo-transcoders should die
  • Comment #181: utf-32-codec is useless
  • Comment #182: Port predicates (New predicates wanted for different subtypes of ports)
  • Comment #183: The standard-*-port procedures should return a fresh binary port
  • Comment #184: SRFI-39 should be made an R6RS library
  • Comment #185: The mess around line endings (eol-style and line endings completely unspecified)
  • Comment #186: Buffer mode should be specifiable on open-file-input-port
  • Comment #187: Bytevectors: `big' and `little' endianness under-specified
  • Comment #188: Add symbol=? and boolean=?
  • Comment #189: hash-table-hash-function should return a function
  • Comment #190: Confusing comparison with Pascal call-by-reference
  • Comment #191: Datum values, shared structure and eq? vs equal?
  • Comment #192: Bytevectors: Sections 2.5 and 2.6 are inappropriately structured
  • Comment #193: proc in hash-table-update! should not mutate hash-table
  • Comment #194: hash-table-mutable? vs hash-table-immutable?
  • Comment #195: procedures passed to make-hash-table should not mutate the hash table
  • Comment #196: modified interface to list-sort and vector-sort
  • Comment #197: I/O: `call-with-port' and multiple returns
  • Comment #198: Allow compilers to reject obvious violations
  • Comment #199: right shift formula and bit-field signedness
  • Comment #200: I/O: Bytevector output ports and `set-port-position!'
  • Comment #201: bytevector aliasing severely impedes optimizations
  • Comment #202: Minor wording issues
  • Comment #203: ->exact and ->inexact should be renamed
  • Comment #204: freshness and mutability of quasiquoted structure should be specified
  • Comment #205: add list* or cons*
  • Comment #206: Scheme-6 should be differentiated from earlier versions
  • Comment #207: combine syntactic record layers
  • Comment #208: eliminate library export immutability loophole
  • Comment #209: Syntactic datums and datum values
  • Comment #210: Why are simple conditions so different from records
  • Comment #211: Remove the (r6rs when-unless) library
  • Comment #212: body should allow mixing declarations with expressions
  • Comment #213: defer lambda rather than define rhs when expanding body
  • Comment #214: assorted small fixes and minor suggestions
  • Comment #215: The name bytevector should be hyphenated
  • Comment #216: Capitalize "Boolean."
  • Comment #217: eol-style: Explain what the identifier "ls" means
  • Comment #218: 5.1. Requirement levels is MAXxed out
  • Comment #219: the procedural record layer needs better examples
  • Comment #220: Map returning twice
  • Comment #221: Recursive exception handling considered harmful
  • Comment #222: Formal semantics should not contain complicating optimizations
  • Comment #223: allow port position to be "magic cookie"
  • Comment #224: get-bytevector-some may be difficult to implement
  • Comment #225: need make-custom-textual-input-port and make-custom-textual-output-port
  • Comment #226: Drop formal semantics of library toplevel
  • Comment #227: Remove DEFINE and BEGIN^F from formal semantics
  • Comment #228: The components of a compound condition should be independent
  • Comment #229: ports, characters, strings, Unicode
  • Comment #230: NaNs are not real numbers
  • Comment #231: Allow inline hex escapes anywhere
  • Comment #232: typewriter font nitpick (incorrect use of monospace in 3.2.5)
  • Comment #233: allow variable-length strings
  • Comment #234: Disallow redefinitions macros/variables
  • Comment #235: String positions and string slices
  • Comment #236: the formal semantics should be a non-normative appendix
    •
    15 Apr 2007