Changes between Initial Version and Version 1 of WG1Ballot5


Ignore:
Timestamp:
07/08/12 08:01:19 (5 years ago)
Author:
alexshinn
Comment:

archiving ballot 5

Legend:

Unmodified
Added
Removed
Modified
  • WG1Ballot5

    v1 v1  
     1= Instructions = 
     2 
     3    * You may list as many of the options as you want in order of preference. 
     4    * Options are comma-delimited (ignoring space) and case-insensitive. 
     5    * You can pipe-delimit (|) options you want to give equal weight to. 
     6    * You may write in your own option if you announce it to the list first. 
     7    * You may specify a variant with option/variant, for example srfi-1/library to vote for srfi-1 but clarify it should be in a separate library. 
     8    * You can write a free-form rationale after the "preferences" line, 
     9    * library means "yes, but I want it in a separate library", 
     10    * wg2 means "no, but I think it should go in WG2". 
     11    * undecided means I want to discuss this issue further. 
     12    * Abstain on any item by leaving the preferences blank.  
     13 
     14= WG1 Ballot Items To Finalize By Mar. 31 = 
     15 
     16== WG1 - Core == 
     17 
     18=== #229 Are NaN values EQV? === 
     19 
     20We voted that `eqv?` return `#t` if both arguments are any value which 
     21writes as `+nan.0`.  The description of this item was ill-formed and 
     22confusing, as objected to in: 
     23 
     24http://lists.scheme-reports.org/pipermail/scheme-reports/2011-September/001507.html 
     25 
     26We therefore are re-opening the item, with amended descriptions. 
     27 
     28The `different` proposal is that we add a single clause requiring 
     29`(eqv? +nan.0 x)` to return `#f` for any `x`.  This is the behavior 
     30that results for any R5RS implementation that adds support for +nan.0 
     31as an IEEE float without any special handling for it in `eqv?`. 
     32 
     33The `unspecified` proposal is to make the results explicitly unspecified, 
     34as specified in R6RS. 
     35 
     36The `same` proposal, contrary to both standards, is that we add a clause to 
     37the definition of `eqv?` saying that if both arguments are NaN 
     38values with the same bit pattern, `eqv?` must return `#t`.  Thus `eq?` 
     39implies `eqv?`.  However, if two values both print as `+nan.0` they 
     40may or may not be `eqv?`.  This also requires additional checks for 
     41floating point comparisons. 
     42 
     43Testing with `(equal? (/ 0.0 0.0) (/ 0.0 0.0))` to get the same 
     44bit pattern but non-object-identity, we get the following results: 
     45 
     46The following 8 implementations return #t: Chez, Gambit, Guile, Ikarus/Vicare, Kawa, Larceny, Racket, STklos. 
     47 
     48The following 6 implementations return #f: Bigloo, Chibi, Chicken, Gauche, MIT Scheme, Scheme48. 
     49 
     50SigScheme and Scheme 9 don't have `+nan.0`. SISC currently has a bug 
     51where `(= nan.0 x)` is true for any `x`. 
     52 
     53 
     54  * '''Options:''' same, different, unspecified, undecided 
     55  * '''Default:''' unspecified 
     56  * '''Preferences:'''  
     57 
     58=== #275 Support -nan.0 as a synonym for +nan.0 === 
     59 
     60Excluding `-nan.0` was an oversight, and it's gratuitously 
     61incompatible with R6RS as well as current practice.  Racket, Gauche, 
     62Chicken, Guile, Chez, Ikarus, Larceny, Ypsilon, STklos all support 
     63`+nan.0` and `-nan.0` as equivalent forms.  MIT, Bigloo, Scheme48/scsh, 
     64SISC, SCM, Scheme 9 don't support either form.  Only Gambit and Chibi 
     65support `+nan.0` but not `-nan.0`. 
     66 
     67STklos prints both `+nan.0` and `-nan.0` as `-nan.0`. 
     68 
     69Vote `yes` to allow `-nan.0`, `no` to disallow it. 
     70 
     71  * '''Options:''' yes, no, undecided 
     72  * '''Default:''' no 
     73  * '''Preferences:'''  
     74 
     75=== #278 Shrink division routines to just truncate and floor === 
     76 
     77Bradley Lucier says: 
     78 
     79I don't see the `centered-*` operators as somehow a "completion" of 
     80the other division operators.  In the small language I'd recommend 
     81only the `truncate-*` and `floor-*` operators for two reasons: they 
     82are the only division operators that have an established history of 
     83use in computer programming and mathematics, and they form a minimal 
     84extension of R5RS.  (I'm not saying that the other division operators 
     85have never been used in mathematics or programming (see CL), but small 
     86Scheme is not supposed to be a kitchen-sink language.) 
     87 
     88Vote `shrink` to prune to `truncate-*` (R5RS) and `floor-*` (R5RS `modulo`), moving 
     89the extra operators to the large language; `shrink/core` to do the same as `shrink` 
     90but move the remaining operators to the core language; or `keep` to keep all 18 
     91division operators in the small language. 
     92 
     93  * '''Options:''' shrink, shrink/core, keep, undecided 
     94  * '''Default:''' keep 
     95  * '''Preferences:'''  
     96 
     97=== #280 Make vectors self-quoting === 
     98 
     99Currently vectors are the only type represented by a readable datum 
     100that are neither self-quoting nor meaningful Scheme expressions 
     101(i.e. symbols and lists).  The proposal is to make them 
     102self-quoting as well. 
     103 
     104Currently Racket, Gauche, MIT, Guile, Kawa, Chibi, SCM, STklos, Scheme 
     1059, Scheme 7, UMB, VX, Oaklisp treat vectors as self-quoting. 
     106 
     107Gambit, Chicken, Bigloo, Scheme48/scsh, SISC, Ikarus, Larceny, 
     108Ypsilon, !IronScheme, Mosh, KSi, !SigScheme, Elk treat unquoted 
     109vectors as errors. 
     110 
     111Vote `yes` to make them self-quoting, `no` to make it an explicit 
     112error, or `unspecified` to leave unspecified as in R5RS. 
     113 
     114The only other reasonable alternative semantics for this unspecified 
     115case would be to treat #(...) as (vector ...) (i.e. in contrast to this proposal 
     116to evaluate the contents rather than quoting them).  No known 
     117implementations make this extension, and it is dubious due to the 
     118fact that it makes what appears to be quoted data to be evaluated, 
     119and so is not listed as an option.  The possibility of this extension, 
     120however, could serve as an argument to leave it unspecified. 
     121 
     122  * '''Options:''' yes, no, unspecified, undecided 
     123  * '''Default:''' unspecified 
     124  * '''Preferences:'''  
     125 
     126=== #282 Map and friends should call their procedures in the same dynamic environment === 
     127 
     128The specifications of `map`, `for-each`, and other procedures that 
     129accept a procedure as an argument and call it, should specify that the 
     130argument procedures will always be called in the dynamic environment 
     131of the call to `map`, `for-each`, etc. 
     132 
     133This is an R6RS fix. 
     134 
     135Vote `yes` to add the clarification and `no` to leave it out. 
     136 
     137  * '''Options:''' yes, no, undecided 
     138  * '''Default:''' no 
     139  * '''Preferences:'''  
     140 
     141=== #283 Initial characters in non-ASCII identifiers should exclude digits and combiners === 
     142 
     143Identifiers beginning with a character of type Nd, Mc, or Me should be 
     144forbidden.  This is an R6RS issue. 
     145 
     146Nd is a numeric character, which in the case of ASCII 0-9 is already 
     147forbidden, but currently unspecified for non-ASCII digits. 
     148 
     149Mc and Me are enclosing marks and spacing combining marks respectively, which are logically attached to the preceding character. 
     150 
     151Vote `yes` to forbid (which would still allow this as an 
     152implementation-dependent extension for either numbers or symbols). 
     153 
     154  * '''Options:''' yes, no, undecided 
     155  * '''Default:''' no 
     156  * '''Preferences:'''  
     157 
     158=== #285 R6RS base compatibility: symbol=? === 
     159 
     160This is equivalent to `eq?` on symbols, and provides R6RS base 
     161compatibility as well as completing the set of type-specific 
     162comparisons.  See also #316. 
     163 
     164Vote `yes` to add this procedure. 
     165 
     166  * '''Options:''' yes, no, undecided 
     167  * '''Default:''' no 
     168  * '''Preferences:'''  
     169 
     170=== #286 Numeric *-valued procedures for R5RS and R6RS-base compatibility === 
     171 
     172`Real-valued?`, `rational-valued?`, and `integer-valued?` test whether 
     173a given number object can be coerced to the specified type without 
     174loss of numerical accuracy.  They are equivalent to the versions of 
     175`real?`, `rational?`, and `integer?` that exist in R5RS. 
     176 
     177Specifically, the behavior of these predicates differs from the 
     178behavior of `real?`, `rational?`, and `integer?` on complex number 
     179objects whose imaginary part is inexact zero. 
     180 
     181These procedures provide R6RS base compatibility as well. 
     182 
     183 * Vote `yes` to add `*-valued` procedures; 
     184 * Vote `no` to leave out the `*-valued` procedures; 
     185 * Vote `r5rs` to leave them out ''and'' revert `real?`, `rational?`, and `integer?` to R5RS semantics 
     186 * vote `r5rs+strictly` to do what `r5rs` does, and also add `strictly-*?` procedures to provide the R6RS semantics of `real?`, `rational?`, and `integer?`. 
     187 
     188  * '''Options:''' yes, no, undecided 
     189  * '''Default:''' no 
     190  * '''Preferences:'''  
     191 
     192=== #287 R6RS base compatibility: assert === 
     193 
     194`Assert` raises an error if its argument is `#f`.  This provides R6RS 
     195base compatibility. 
     196 
     197Vote `basic` to add this syntax.  Vote `optionals` to make `assert` optionally accept, after its 
     198expression argument, a single `message` argument and zero or more `irritant` arguments 
     199in the same manner as the `error` procedure.  Vote `no` in order not to add `assert`. 
     200 
     201  * '''Options:''' basic, optionals, no, undecided 
     202  * '''Default:''' no 
     203  * '''Preferences:'''  
     204 
     205=== #288 R6RS base compatibility: infinite? === 
     206 
     207`Infinite?` returns `#t` if its value is a real number, or if its 
     208value is a complex number and either the real or the imaginary part 
     209would return `#t` to `infinite?`.  This provides R6RS base 
     210compatibility, with extensions for complex numbers analogous to that 
     211provided by `finite?` and `nan?`. 
     212 
     213This was in the draft at one point, but was never actually voted on, 
     214so the editors removed it. 
     215 
     216Vote `yes` to add this procedure. 
     217 
     218  * '''Options:''' yes, no, undecided 
     219  * '''Default:''' no 
     220  * '''Preferences:'''  
     221 
     222== WG1 - Numerics == 
     223 
     224=== #290 Proposed square procedure === 
     225 
     226Bradley Lucier writes (lightly edited): 
     227 
     228A `square` primitive is useful in calculating with bignums because 
     229squaring a bignum is generally cheaper than multiplying two different 
     230bignums of the same size. For example, Gambit's runtime checks 
     231trivially whether the two arguments in `(* a b)` are `eq?` before 
     232calling the appropriate algorithm.  Generally, it may be better to be 
     233able to express this primitive directly. 
     234 
     235[He also points out that given `square` in the small language, we can 
     236have `flsquare` in the large language, though having the 
     237latter doesn't actually require having the former.] 
     238 
     239In addition, there are 20,340 Google hits for ["(define (square x)" ss|scm]. 
     240 
     241Vote `yes` to add this procedure. 
     242 
     243  * '''Options:''' yes, no, undecided 
     244  * '''Default:''' no 
     245  * '''Preferences:'''  
     246 
     247== WG1 - Core == 
     248 
     249=== #291 Require an error to be signalled if input files cannot be opened === 
     250 
     251For `with-input-from-file`, `with-output-to-file`, 
     252`call-with-input-file`, `call-with-output-file`, R5RS just says that 
     253the file should exist.  However, `open-input-file` requires an error 
     254to be signalled if the file cannot be opened, whether because it does 
     255not exist for some other reason like the lack of permissions.  This 
     256inconsistency doesn't seem useful. 
     257 
     258The proposal is to change these wrapper procedures to also require an error 
     259to be signalled if the file cannot be opened.  All major Schemes 
     260already implement this. 
     261 
     262Vote `yes` to require signalling an error if the files cannot be opened. 
     263 
     264  * '''Options:''' yes, no, undecided 
     265  * '''Default:''' no 
     266  * '''Preferences:'''  
     267 
     268=== #292 Add case-insensitive normalization-insensitive comparisons === 
     269 
     270mdmkolbe writes on Slashdot: 
     271 
     272Given that on a system with Unicode, you almost never want to do a 
     273non-normalizing case-insensitive match and that it is hard for a user 
     274to efficiently implement their own normalizing case-insensitive match, 
     275it seems an odd corner of the rectangle to omit. 
     276 
     277(end quotation) 
     278 
     279Alternatively we could specify that `-ci` procedures always normalize, 
     280or that `-ni` procedures are always case-insensitive, since the 
     281details of the normalization are not exposed anyway. 
     282 
     283  * '''Proposals:''' 
     284    * '''normalize-ci:''' specify that *-ni procedures normalize their arguments 
     285    * '''case-fold-ni:''' specify that *-ni procedures case-fold their arguments 
     286    * '''ci-ni:''' add new *-ci-ni procedures that perform both operations 
     287    * '''none:''' leave as-is, although *-ni may still fold 
     288    * '''remove:''' remove the *-ni procedures altogether 
     289    * '''remove+normalize-ci:''' remove *-ni procedures, allow *-ci procedures to normalize 
     290  * '''Options:''' normalize-ci, case-fold-ni, ci-ni, remove, none 
     291  * '''Default:''' none 
     292  * '''Preferences:'''  
     293 
     294=== #293 Make it an error for <test> values to return other than one value === 
     295 
     296Currently nothing is said about the <test> of `if`, `cond`, `and`, 
     297`or`, etc. returning zero values or multiple values.  The proposal is 
     298to make this an explicit error.  Remember that this does not mean an error is 
     299''signalled''. 
     300 
     301Vote `yes` to make an explicit error. 
     302 
     303  * '''Options:''' yes, no, undecided 
     304  * '''Default:''' no 
     305  * '''Preferences:'''  
     306 
     307=== #294 Make it an error for the <expression> of a set! to return other than one value === 
     308 
     309Currently nothing is said about what happens if the <expression> of a 
     310`set!` returns zero values or multiple values.  The proposal is to make this 
     311an explicit error.  Remember that this does not mean an error is 
     312''signalled''. 
     313 
     314Vote `yes` to make an explicit error. 
     315 
     316  * '''Options:''' yes, no, undecided 
     317  * '''Default:''' no 
     318  * '''Preferences:'''  
     319 
     320=== #295 Make it an error for <init>s in binding forms to return other than one value === 
     321 
     322Right now nothing is said.  The proposal is to make this 
     323an explicit error.  Remember that this does not mean an error is 
     324''signalled''. 
     325 
     326Vote `yes` to make an explicit error. 
     327 
     328  * '''Options:''' yes, no, undecided 
     329  * '''Default:''' no 
     330  * '''Preferences:'''  
     331 
     332=== #297 Removing case-folding flags === 
     333 
     334The case-folding flags `#!fold-case` and `#!no-fold-case` are the only 
     335reader flags in the draft, however their need is reduced (though not 
     336eliminated) by the library declaration `include-ci`.  Do we still need 
     337flipflop flags to turn case-folding on and off in part of a file? 
     338 
     339If we remove these we maintain backwards compatibility with R5RS 
     340library code, however we lose the ability to support R5RS programs or 
     341toggle case-folding in the REPL or data files, etc. 
     342 
     343  * '''Options:''' keep, remove, undecided 
     344  * '''Default:''' keep 
     345  * '''Preferences:'''  
     346 
     347=== #303 "lazy" is a confusing name === 
     348 
     349[Based on feedback from Marc Feeley.] 
     350 
     351`delay` and `force` were simple balanced concepts, but the 
     352introduction of `lazy` somewhat confuses the issue - when is `delay` 
     353appropriate and when is `lazy`?  A simple solution would be to rename 
     354`lazy` to `delay-force`, indicating it is simply the composition of 
     355`delay` and `force`, and letting people see directly in code the 
     356balance of `delay`s and `force`s. 
     357 
     358  * '''Options:''' delay-force, lazy, undecided 
     359  * '''Default:''' lazy 
     360  * '''Preferences:'''  
     361 
     362=== #304 symbol literal syntax wastes characters === 
     363 
     364[Based on feedback from Marc Feeley.] 
     365 
     366Currently symbols can either be delimited with pipes |...| 
     367with optional hex escapes inside, or include hex escapes 
     368directly without the pipes.  This wastes two characters 
     369that were reserved in R5RS, the pipe and the backslash, 
     370when either one by itself would be sufficient to represent 
     371all symbols.  This is especially unfortunate because both 
     372characters are used as extensions in various Schemes - 
     373the pipe being another symbol character in SCSH (to 
     374represent shell-style pipes and C-style operators) and 
     375the backslash used in Gambit's infix syntax.  We should 
     376reconsider if we really need to take up both of these 
     377characters. 
     378 
     379We can also consider new sequences, for instance \|...| 
     380with optional hex escapes inside uses only \, has the 
     381readability advantages of |...|, and still leaves room for 
     382other \ escapes since the following | character is required. 
     383However, such new sequences have no existing support 
     384among implementations. 
     385 
     386  * '''Proposals:'''  
     387    * '''delimited-only:''' |...| syntax with internal escapes, \ outside is undefined, Gambit-compatible 
     388    * '''backslash-only:''' \xNN; only, with | valid in identifiers, SCSH-compatible 
     389    * '''both:''' both as in the current draft 
     390    * '''neither:''' remove both 
     391    * '''backslash-delimited:''' \|...| syntax with internal escapes 
     392  * '''Options:''' delimited-only, backslash-only, both, neither, backslash-delimited, undecided 
     393  * '''Default:''' both 
     394  * '''Preferences:'''  
     395 
     396=== #305 Should we move the c...r and c....r procedures into a new library? === 
     397 
     398They have been required for a long time, but Alex Shinn says: 
     399 
     400I definitely think everything but the one and two depth combinations 
     401should be removed from `(scheme base)`.  Their use is generally a code 
     402smell.  People should use destructuring, records, or SRFI-1 
     403`first..tenth` accessors. 
     404 
     405Ray Dillinger (Bear) adds: 
     406 
     407The historic use of these entities was as accessors for structured 
     408aggregates implemented with cons cells.  In a language that directly 
     409supports records, they have a reduced mission. 
     410 
     411Vote `base` to keep all in the base library or `library` to move the 3- and 4-letter accessors to a separate library. 
     412 
     413  * '''Options:''' base, library, remove, undecided 
     414  * '''Default:''' base 
     415  * '''Preferences:'''  
     416 
     417=== #307 "eager" is a confusing name === 
     418 
     419[Based on feedback from Marc Feeley] 
     420 
     421The `eager` procedure is named particularly unfortunately because it 
     422sounds as though it is in some way paired with `lazy`, and there is 
     423anecdotal evidence it was voted in on this misunderstanding.  In fact, 
     424it is completely unrelated to `lazy`, being just a utility procedure 
     425that has never been seen used in practice.  Perhaps a better name for 
     426it would be `promise` or `make-promise`, since it just creates an 
     427(already computed) promise value. 
     428 
     429Vote `eager`, `promise` or `make-promise` to specify the name, or 
     430`remove` to remove this procedure altogether. 
     431 
     432  * '''Options:''' eager, promise, make-promise, remove, undecided 
     433  * '''Default:''' eager 
     434  * '''Preferences:'''  
     435 
     436=== #308 Allow circular lists in LIST-REF for SRFI-1 compatibility === 
     437 
     438Allow the argument of `list-ref` to be circular.  It is still an error 
     439to use an index >= the length of the list.  None of my test 
     440implementations has a problem with this. 
     441 
     442Vote `circular` to explicitly allow circular lists, `error` to add an 
     443"is an error" disclaimer, or `unspecified` to leave as is. 
     444 
     445  * '''Options:''' circular, error, unspecified, undecided 
     446  * '''Default:''' unspecified 
     447  * '''Preferences:'''  
     448 
     449=== #309 Allow circular lists in MAP and FOR-EACH for SRFI-1 compatibility === 
     450 
     451Allow circular lists as the list arguments to `map` and `for-each`. If 
     452all arguments are circular, these procedures will not terminate unless 
     453the mapping procedure forces a non-local exit.  The result of `map` is 
     454not circular.  Implementations that stop when the shortest list runs 
     455out and don't make gratuitous tests shouldn't have a problem with 
     456this: R5RS allows, R6RS forbids, and R7RS requires this behavior. 
     457 
     458Vote `circular` to explicitly allow circular lists, `error` to add an 
     459"is an error" disclaimer, or `unspecified` to leave as is. 
     460Unspecified leaves open the theoretical extension of returning a new 
     461circular list with the corresponding mapped results. 
     462 
     463  * '''Options:''' circular, error, unspecified, undecided 
     464  * '''Default:''' unspecified 
     465  * '''Preferences:'''  
     466 
     467=== #310 Rationalize start/end/(fill) arguments in sequence procedures === 
     468 
     469When we approved CompleteSequenceCowan in ticket #64, we adopted 
     470[http://srfi.schemers.org/srfi-43/srfi-43.html#vector-fill-bang SRFI 
     47143] syntax and semantics for `vector-copy`, meaning that it takes 
     472optional ''start, end, fill'' arguments.  This is inconsistent with 
     473various other copier procedures in R7RS as inherited from R5RS, as 
     474well as what is provided in SRFI 43 and its relatives 
     475[http://srfi.schemers.org/srfi-1/srfi-1.html SRFI 1] (for lists) and 
     476[http://srfi.schemers.org/srfi-13/srfi-13.html SRFI 13] (for strings). 
     477There are four plausible courses of action: 
     478 
     479  * '''Proposals:''' 
     480    * ''nothing'' (default):  The only virtue here is that it requires the least thinking and editing.  Several comments have criticized it. 
     481    * ''r5rs:''  Claw back ``vector-copy`` to just accept the source vector, all of which is to be copied.  This provides self-consistency, consistency with R5RS, and maximum simplicity.  The SRFIs will be provided as R7RS-large packages which will export the more complex and powerful versions. 
     482    * ''srfi:''  Enhance `vector-fill!`, `vector->list`, `string->list`, `string-copy`, `string-fill!` to support optional ''start'' and ''end'' arguments.  This provides some self-consistency, backward compatibility with R5RS, consistency with the SRFIs, and some loss of simplicity. 
     483    * ''srfi-plus:''  Same as ''SRFIs'', but also add optional ''start, end, fill'' arguments to `list-copy` and optional ''fill'' argument to `string-copy`.  This provides maximal function, full self-consistency, backward compatibility with R5RS, and backward compatibility with the SRFIs. 
     484  * '''Options:''' nothing, r5rs, srfi, srfi-plus, undecided 
     485  * '''Default:''' nothing 
     486  * '''Preferences:'''  
     487 
     488=== #311 Remove tail call guarantee for guard clauses === 
     489 
     490The current draft guarantees the guard clauses (not the body) of a 
     491guard form to be in tail call position, but the need for this is 
     492unclear (who needs an unbounded number of active exceptions), and 
     493there may be worthwhile guard implementations where this is not the 
     494case. 
     495 
     496  * '''Options:''' remove, keep, undecided 
     497  * '''Default:''' keep 
     498  * '''Preferences:'''  
     499 
     500=== #312 unquoting and identifiers beginning with @ === 
     501 
     502The current draft allows `@` to begin an identifier, which would require 
     503some comment about unquoting, i.e. to distinguish whether `,@foo` is 
     504`(unquote @foo)` or `(unquote-splicing foo)`. 
     505 
     506The options are `invalid` (disallow @ at the beginning of an 
     507identifier, as in R5RS), `unquote` to indicate that `,@foo` is `(unquote @foo)`, and 
     508`unquote-splicing` to indicate that `,@foo` is `(unquote-splicing foo)`. 
     509 
     510If `unquote-splicing` is chosen, a 
     511note will be added saying that if you want to unquote an identifier beginning with `@` you 
     512need to either insert whitespace or escape the identifier, e.g. either `, @foo` 
     513or `,|@foo|`. 
     514 
     515Note that if we don't choose `invalid` then SXML retroactively becomes 
     516valid syntax. 
     517 
     518  * '''Options:''' invalid, unquote, unquote-splicing, unspecified, undecided 
     519  * '''Default:''' unspecified 
     520  * '''Preferences:'''  
     521 
     522=== #315 null character may not be usable in strings === 
     523 
     524We should probably make (string-set! str n #\null) unspecified.  Note that R7RS implementations can already restrict the set of characters that are allowed in strings. 
     525 
     526Vote `yes` to add a clause to this effect, and `no` to leave it as legal. 
     527 
     528  * '''Options:''' yes, no, undecided 
     529  * '''Default:''' yes 
     530  * '''Preferences:'''  
     531 
     532=== #316 R6RS base compatibility: boolean=? === 
     533 
     534This is equivalent to `eq?` on booleans, and provides R6RS base 
     535compatibility as well as completing the set of type-specific 
     536comparisons.  See also #285. 
     537 
     538Vote `yes` to add these three procedures. 
     539 
     540  * '''Options:''' yes, no, undecided 
     541  * '''Default:''' no 
     542  * '''Preferences:'''  
     543 
     544=== #317 escape from with-input-from-file === 
     545 
     546The draft states for with-input-from-file and with-output-to-file: 
     547 
     548  If an escape procedure is used to escape 
     549  from the continuation of these procedures, their 
     550  behavior is implementation-dependent. 
     551 
     552but now that we have dynamic-wind there's no particular reason to keep 
     553this restriction, nor is it difficult to implement. 
     554 
     555Vote `parameterize` to specify the current-in/output-port are bound 
     556dynamically as with parameterize in these cases, or `unspecified` to 
     557leave unspecified. 
     558 
     559  * '''Options:''' parameterize, unspecified, undecided 
     560  * '''Default:''' unspecified 
     561  * '''Preferences:'''  
     562 
     563=== #319 Make special treatment of CAPITAL SIGMA optional === 
     564 
     565Currently we require that if the characters GREEK LETTER CAPITAL 
     566SIGMA, SMALL SIGMA, and SMALL FINAL SIGMA are supported by an 
     567implementation, that a CAPITAL SIGMA in a string passed to 
     568`string-downcase` be changed to SMALL FINAL SIGMA just before a word 
     569break, and SMALL SIGMA otherwise.  Word breaks are defined by UAX #29, 
     570and are no simple matter.  The proposal is to make this behavior optional, 
     571allowing CAPITAL SIGMA to be downcased to SMALL SIGMA in every case. 
     572 
     573Vote `yes` to make optional. 
     574 
     575  * '''Options:''' yes, no, undecided 
     576  * '''Default:''' no 
     577  * '''Preferences:'''  
     578 
     579=== #320 Add new cond-expand feature to Appendix B: exact-complex === 
     580 
     581(In this ticket, "complex" is used for readability; it is synonymous 
     582with "non-real".) 
     583 
     584This feature is true in implementations that support complex numbers 
     585such that both the real and the imaginary parts are exact; that is, if 
     586`(eqv? 3+4i 3.0+4.0i)` evaluates to `#f`.  This feature is false if 
     587complex numbers are not supported or if only inexact complex numbers 
     588are supported.  Most of the applications of complex numbers use 
     589inexact numbers, but some applications may require exactness: this 
     590feature allows those applications to fail fast on implementations that 
     591cannot support them. 
     592 
     593Existing implementations: 
     594 
     595* Exact complex numbers: Racket, MIT, Gambit, Chicken with the `numbers` egg, Scheme48/scsh, Kawa, Chibi, Chez, Vicare, Ypsilon, Mosh, !IronScheme, STklos, Wraith  
     596* No exact complex numbers: Gauche, Guile, SISC, SCM, Scheme 7, KSi, UMB, Stalin  
     597* No complex numbers: Chicken without the `numbers` egg, Bigloo, Ikarus, RScheme, Scheme 9, Oaklisp, Elk, VX, Sixx, Sizzle, Dream, Owl Lisp, Psyche 
     598 
     599Vote `yes` to add this feature. 
     600 
     601  * '''Options:''' yes, no, undecided 
     602  * '''Default:''' no 
     603  * '''Preferences:'''  
     604 
     605=== #321 Add get-features from EnvironmentEnquiriesCowan to R7RS-small === 
     606 
     607This procedure returns a list of symbols corresponding to the feature 
     608identifiers which the implementation treats as true.  More details at 
     609EnvironmentEnquiriesCowan. 
     610 
     611Vote `yes` to add this procedure. 
     612 
     613  * '''Options:''' yes, no, wg2, undecided 
     614  * '''Default:''' no 
     615  * '''Preferences:'''  
     616 
     617=== #322 Add EnvironmentEnquiriesCowan (other than get-features) to R7RS-small === 
     618 
     619EnvironmentEnquiriesCowan is a library providing ''at run time'' what 
     620Common Lisp calls environment enquiries such as the name of the OS. 
     621Implementations can currently expose these as `cond-expand` feature 
     622identifiers, but there is no way to determine things like the name of 
     623the implementation at run time so that it can be written to a log 
     624file, for example. 
     625 
     626Vote `yes` to add EnvironmentEnquiriesCowan (other than 
     627`get-features`), and `no` to leave out. 
     628 
     629  * '''Options:''' yes, no, wg2, undecided 
     630  * '''Default:''' no 
     631  * '''Preferences:'''  
     632 
     633=== #323 Eliminate some cond-expand feature identifiers === 
     634 
     635Reduce the standardized `cond-expand` feature identifiers to `r7rs`, 
     636`exact-closed`, `ratio`s, `ieee-float`, and `full-unicode`, plus the 
     637name and name-plus-version of the implementation.  The others can't 
     638affect the behavior of strictly conforming programs, and it's not 
     639clear if they apply to compile time or run time on implementations 
     640that distinguish the two.  See also ticket #320 for `exact-complex`. 
     641 
     642Argument against: Keeping them in the standard encourages all 
     643implementations that use them to spell them the same way: `darwin`, 
     644not `macosx`. 
     645 
     646Vote `full` to keep the full list as in draft-6, `implementation` to 
     647keep only the implementation features, or `numerics` to keep the list 
     648described above. 
     649 
     650  * '''Options:''' full, implementation, numerics 
     651  * '''Default:''' full 
     652  * '''Preferences:'''  
     653 
     654=== #259 Remove `(library <name>)` cond-expand features === 
     655 
     656The `(library <name>)` feature test which is true if the given library 
     657is available (at compile time).  This was used because we voted for 
     658CondExpandCowan, but the original syntax was just `<name>` which is 
     659ambiguous and therefore invalid.  The switch to `(library <name>)` was 
     660added editorially, but not officially voted on. 
     661 
     662Vote `keep` to keep and `remove` to remove. 
     663 
     664  * '''Options:''' keep, remove, wg2, undecided 
     665  * '''Default:''' keep 
     666  * '''Preferences:'''  
     667 
     668=== #324 allow |\ as escape for | within a |-escaped identifier === 
     669 
     670Allow `\|` to represent a vertical bar in an identifier enclosed in 
     671vertical bars (the current BNF disallows | anywhere in the escape). 
     672 
     673Note this item is nullified if |...| escapes are removed in item #304. 
     674 
     675Vote `pipe` to allow just the vertical bar escaped, `string` to allow 
     676the same set of escapes as in string literals (plus pipe), and `none` 
     677to leave as is. 
     678 
     679  * '''Options:''' pipe, string, none, undecided 
     680  * '''Default:''' none 
     681  * '''Preferences:'''  
     682 
     683=== #325 Eliminate bytevector-copy! === 
     684 
     685`(bytevector-copy! from to)` is equivalent to 
     686`(bytevector-copy-partial! from 0 (bytevector-length) to 0)`.  
     687 
     688The proposal is to remove the existing `bytevector-copy!` from the 
     689small language, and rename `bytevector-copy-partial!` to 
     690`bytevector-copy!`, with the order of arguments `to at from start 
     691end`, the same order used in SRFI 43's `vector-copy!`.  Note that SRFI 
     69243 will be part of the large language. 
     693 
     694Vote `yes` to eliminate and rename as proposed, and `no` to leave 
     695as-is. 
     696 
     697  * '''Options:''' yes, no, undecided 
     698  * '''Default:''' no 
     699  * '''Preferences:'''  
     700 
     701=== #326 Add destructive list-copy!, string-copy!, and vector-copy! === 
     702 
     703From Per Bothner: 
     704 
     705Copying a slice from one vector/string into another is such a 
     706fundamental operation that it should be added, IMO, considering that 
     707it's tedious to write if "by hand", and that a standard library 
     708routine is likely to be much more efficient (especially for strings, 
     709since that avoids the need for boxing and unboxing the characters). 
     710[JC: Many implementations represent characters as immediates, 
     711however.] 
     712 
     713One could also argue that "character" operations don't really make 
     714semantic sense in a Unicode world, and so `string-set!` has limited 
     715usefulness.  Thus `string-copy` [with start/end arguments] and 
     716`string-copy!` are the actual useful "primitive" operations. 
     717 
     718JC: These would be the five-argument versions based on the current 
     719`bytevector-copy-partial!`, possibly with renumbering of arguments 
     720depending on the outcome of #325. 
     721 
     722Vote `yes` to add these destructive operations as proposed, `nolist` to add `string-copy!` and `vector-copy!` only, or `no` for none of them. 
     723 
     724  * '''Options:''' yes, nolist, no, undecided 
     725  * '''Default:''' no 
     726  * '''Preferences:'''  
     727 
     728=== #327 Specify that read, the program reader, and string->number accept the same syntax === 
     729 
     730Currently there is no guarantee of this.  Obviously the 
     731`string->number` only applies to the case where the radix is 10 or 
     732specified. 
     733 
     734Specifying `same` is problematic in the presence of batch compilation 
     735- the compile-time and runtime may not even support the same numeric 
     736tower. 
     737 
     738  * '''Proposals:''' 
     739    * ''same'': The lexical syntax for numbers accepted by `string->number` and `read`, as well as the corresponding syntax of literal numbers in programs, must be the same. 
     740    * ''run-time'': The lexical syntax for numbers accepted by `string->number` and `read` must be the same, but the relationship with the the corresponding syntax of literal numbers in programs is unspecified. 
     741    * ''unspecified'': The relationships between lexical syntax for numbers accepted by `string->number` and `read`, as well as the corresponding syntax of literal numbers in programs, is unspecified. 
     742  * '''Options:''' same, run-time, unspecified, undecided 
     743  * '''Default:''' unspecified 
     744  * '''Preferences:'''  
     745 
     746=== #328 names for inexact->exact and exact->inexact === 
     747 
     748R6RS changed these names to the more sensible exact and inexact. 
     749We need to decide if we want to follow suit, or provide both names, 
     750or write a disclaimer. 
     751 
     752Vote `r6rs` for the short names, `r5rs` for the long names, or `both` 
     753for both. 
     754 
     755  * '''Options:''' r5rs, r6rs, both, undecided 
     756  * '''Default:''' r5rs 
     757  * '''Preferences:'''  
     758 
     759=== #329 Add IEEE compatibility library === 
     760 
     761The `(scheme ieee)` library exports the standard identifiers of IEEE 
     7621178-1990.  By my current reckoning, those identifiers are as follows: 
     763 
     764`- * / + < <= = > >= abs acos and angle append apply asin assoc assq 
     765assv atan begin boolean? call-with-current-continuation car case cdr 
     766ceiling char->integer char-alphabetic? char-ci<? char-ci<=? char-ci=? 
     767char-ci>? char-ci>=? char-downcase char-lower-case? char-numeric? 
     768char-upcase char-upper-case? char-whitespace? char? char<? char<=? 
     769char=? char>? char>=? close-input-port close-output-port complex? cond 
     770cons cos current-input-port current-output-port define denominator 
     771display do eof-object? eq? equal? eqv? even? exact->inexact exact? exp 
     772expt floor for-each gcd if imag-part inexact->exact inexact? 
     773input-port? integer->char integer? lambda lcm length let let* letrec 
     774list list-ref list? log magnitude make-polar make-rectangular 
     775make-string make-vector map max member memq memv min modulo negative? 
     776newline not null? number->string number? numerator odd? 
     777open-input-file open-output-file or output-port? pair? peek-char 
     778positive? procedure? quasiquote quote quotient rational? rationalize 
     779read read-char real-part real? remainder reverse round set-car! 
     780set-cdr! set! sin sqrt string string->number string->symbol 
     781string-append string-ci<? string-ci<=? string-ci=? string-ci>? 
     782string-ci>=? string-length string-ref string-set! string? string<? 
     783string<=? string=? string>? string>=? substring symbol->string symbol? 
     784tan truncate vector vector-length vector-ref vector-set! vector? write 
     785write-char zero?` 
     786 
     787As with any library other than `(scheme base)`, implementations SHOULD 
     788(rather than MUST) provide this. 
     789 
     790Vote `yes` to add this library. 
     791 
     792  * '''Options:''' yes, no, undecided 
     793  * '''Default:''' no 
     794  * '''Preferences:'''  
     795 
     796=== #330 Add R5RS compatibility library === 
     797 
     798The `(scheme r5rs)` library exports the standard identifiers of R5RS 
     799Scheme other than `transcript-{on,off}`.  By my current reckoning, those identifiers are as follows: 
     800 
     801`- * / + < <= = > >= abs acos and angle append apply asin assoc assq 
     802assv atan begin boolean? call-with-current-continuation 
     803call-with-values car case cdr ceiling char->integer char-alphabetic? 
     804char-ci<? char-ci<=? char-ci=? char-ci>? char-ci>=? char-downcase 
     805char-lower-case? char-numeric? char-ready? char-upcase 
     806char-upper-case? char-whitespace? char? char<? char<=? char=? char>? 
     807char>=? close-input-port close-output-port complex? cond cons cos 
     808current-input-port current-output-port define define-syntax delay 
     809denominator display do dynamic-wind eof-object? eq? equal? eqv? eval 
     810even? exact->inexact exact? exp expt floor for-each force gcd if 
     811imag-part inexact->exact inexact? input-port? integer->char integer? 
     812interaction-environment lambda lcm length let let-syntax let* letrec 
     813letrec-syntax list list->string list->vector list-ref list-tail list? 
     814load log magnitude make-polar make-rectangular make-string make-vector 
     815map max member memq memv min modulo negative? newline not 
     816null-environment null? number->string number? numerator odd? 
     817open-input-file open-output-file or output-port? pair? peek-char 
     818positive? procedure? quasiquote quote quotient rational? rationalize 
     819read read-char real-part real? remainder reverse round 
     820scheme-report-environment set-car! set-cdr! set! sin sqrt string 
     821string->list string->number string->symbol string-append string-ci<? 
     822string-ci<=? string-ci=? string-ci>? string-ci>=? string-copy 
     823string-fill! string-length string-ref string-set! string? string<? 
     824string<=? string=? string>? string>=? substring symbol->string symbol? 
     825tan truncate values vector vector->list vector-fill! vector-length 
     826vector-ref vector-set! vector? with-input-from-file 
     827with-output-to-file write write-char zero?` 
     828 
     829As with any library other than `(scheme base)`, implementations SHOULD 
     830(rather than MUST) provide this.  A disclaimer will be added that the 
     831semantics may not be exactly the same. 
     832 
     833Vote `yes` to add this library. 
     834 
     835  * '''Options:''' yes, no, undecided 
     836  * '''Default:''' no 
     837  * '''Preferences:'''  
     838 
     839=== #331 Add R6RS base compatibility library === 
     840 
     841The `(scheme r6rs base)` library exports the standard identifiers of 
     842the base library of R6RS.  By my current reckoning, those identifiers 
     843are as follows: 
     844 
     845`- * / + < <= = > >= abs acos and angle append apply asin atan begin 
     846boolean? call/cc call-with-current-continuation call-with-values car 
     847case cdr ceiling char? char<? char<=? char=? char>? char>=? 
     848char->integer complex? cond cons cos define define-syntax denominator 
     849dynamic-wind eq? equal? eqv? even? exact exact? exact-integer-sqrt exp 
     850expt finite? floor for-each gcd guard if imag-part import inexact 
     851inexact? integer? integer->char lambda lcm length let let* let*-values 
     852letrec letrec* letrec-syntax let-syntax let-values list list? 
     853list->string list->vector list-ref list-tail log magnitude make-polar 
     854make-rectangular make-string make-vector map max min nan? negative? 
     855not null? number? number->string numerator odd? or pair? positive? 
     856procedure? quasiquote quote rational? rationalize real? real-part 
     857reverse round set! sin sqrt string string? string<? string<=? string=? 
     858string>? string>=? string->list string->number string->symbol 
     859string-append string-copy string-for-each string-length string-ref 
     860substring symbol? symbol->string tan truncate values vector vector? 
     861vector->list vector-fill! vector-for-each vector-length vector-map 
     862vector-ref vector-set! zero?` 
     863 
     864As with any library other than `(scheme base)`, implementations SHOULD 
     865(rather than MUST) provide this.  Full compliance will depend on voting for 
     866the procedures `*-valued`, `assert`, `boolean=?`, `symbol=?`.  A disclaimer 
     867will be added that the semantics will not be exactly the same. 
     868 
     869Vote `yes` to add this library. 
     870 
     871  * '''Options:''' yes, no, undecided 
     872  * '''Default:''' no 
     873  * '''Preferences:'''  
     874 
     875=== #332 Allow multiple name pairs in export renaming === 
     876 
     877Currently, to export `my:foo` and `my:bar` as `foo` and `bar`, one 
     878must write `(export (rename my:foo foo) (rename my:bar bar))`.  This 
     879proposal allows `(export (rename (my:foo foo) (my:bar bar)))`.  This 
     880is incompatible with R6RS, but compatible with the `rename` sub-form 
     881of `import`. 
     882 
     883Vote `multiple` to allow multiple renames in one rename clause as with 
     884the import version, `r6rs` to allow the R6RS-compatible syntax in the 
     885current draft, or `both` to allow both forms. 
     886 
     887  * '''Options:''' r6rs, multiple, both, undecided 
     888  * '''Default:''' r6rs 
     889  * '''Preferences:'''  
     890 
     891=== #333 Require eof-objects to be disjoint from basic Scheme types === 
     892 
     893It's already a requirement that an eof-object cannot have an external 
     894representation, which means it cannot be any of the basic types in 
     895Section 3.2 except procedure or port.  This is very improbable, and in 
     896fact none of my 40 test Schemes returns either a procedure or a port. 
     897 
     898Doing this would allow `eof-object?` to be added to the list of 
     899disjoint type predicates in Section 3.2. 
     900 
     901Vote `yes` to explicitly list the eof-object as a separate disjoint type. 
     902 
     903  * '''Options:'''  
     904  * '''Default:'''  
     905  * '''Preferences:'''  
     906 
     907=== #334 Use proper case for the feature identifiers in Appendix B === 
     908 
     909Specifically R7RS, IEEE-float, full-Unicode, Windows, POSIX, Unix, 
     910Darwin, Linux, BSD, FreeBSD, Solaris, PPC, SPARC, JVM, CLR, LLVM, 
     911ILP32, LP64, ILP64. 
     912 
     913Note this is incompatible with existing implementations which provide 
     914these features.  The correct case can often be ambiguous, and it's 
     915easiest to keep everything consistently lower case. 
     916 
     917Vote `mixed` for mixed case and `lower` for lower case. 
     918 
     919  * '''Options:''' lower, mixed, undecided 
     920  * '''Default:''' lower 
     921  * '''Preferences:'''  
     922 
     923=== #335 Specify behavior of default exception handler === 
     924 
     925If an exception is caught and leaves the current dynamic extent, 
     926obviously the ''after'' thunk must be run, but an uncaught exception has 
     927no semantics and is basically reverting to "is an error" semantics, 
     928i.e. nasal demon territory. 
     929 
     930Possibly we should tighten this up in the standard, i.e. specify that 
     931there is a default exception handler which enters a continuation 
     932outside the extent of the whole program before exiting. 
     933 
     934Vote `unwind` to specify that there is a default exception handler 
     935which leaves the current dynamic extent causing a full unwind (and 
     936thus forbidding a debugger), `exit` to specify that (modulo any 
     937diagnostic information) the program must simply exit without 
     938unwinding, or `unspecified` to leave this as is. 
     939 
     940  * '''Options:''' unwind, exit, unspecified 
     941  * '''Default:''' unspecified 
     942  * '''Preferences:'''  
     943 
     944=== #344 Should dynamic-wind handlers be invoked from EXIT? === 
     945 
     946Currently the report is silent about whether dynamic-wind handlers are 
     947invoked when `exit` is called. 
     948 
     949The options are the same as in #335 above. 
     950 
     951  * '''Options:''' unwind, exit, unspecified 
     952  * '''Default:''' unspecified 
     953  * '''Preferences:'''  
     954 
     955=== #337 Add eof-object procedure === 
     956 
     957`eof-object` returns an object which answers `#t` to `eof-object?`. 
     958This procedure is present in R6RS, where it must return the ''unique'' 
     959end-of-file object; that is not required here. 
     960 
     961From Vincent Manis: 
     962 
     963This isn't just an attempt to create a vain orthogonality; there are 
     964good reasons why arbitrary code might wish to return an eof 
     965object. For example, a DBMS interface might have a routine that 
     966returns one row, as a list or a vector, at a time; after the last, it 
     967is perfectly reasonable to return an eof object. 
     968 
     969An argument against providing this is that the constructor may be 
     970trivially written, as shown [below]. A similar argument could be 
     971applied to `zero?`, `newline`, `quotient`, `remainder`, and `modulo`, 
     972among others. R7RS is not afraid to provide easy-to-implement 
     973procedures in the name of simplicity, orthogonality, or historical 
     974compatibility.  The lack of an eof constructor is worth 
     975remedying. 
     976 
     977{{{ 
     978(let* ((p (open-input-string "")) 
     979       (x (read p))) 
     980  (close-port p) 
     981  x) 
     982}}} 
     983 
     984Vote `eof-object` for a procedure of that name, or `none` to not add any such procedure. 
     985 
     986  * '''Options:''' eof-object, none, undecided 
     987  * '''Default:''' none 
     988  * '''Preferences:'''  
     989 
     990=== #339 Restrict identifiers in library names for compatibility with file system restrictions === 
     991 
     992Currently the identifiers in library names can be any identifier. 
     993Under this proposal, the identifiers must not include any of `| \ ?* < 
     994" : > + [ ] /` or control characters after escapes are expanded. 
     995 
     996If this proposal fails, its content will be included non-normatively 
     997as a ''should not''. 
     998 
     999Vote `yes` to restrict with ''must not''. 
     1000 
     1001  * '''Options:''' yes, no, undecided 
     1002  * '''Default:''' no 
     1003  * '''Preferences:'''  
     1004 
     1005=== #340 Include non-normative note about the file-system based implementations of libraries === 
     1006 
     1007Libraries do not necessarily have any mapping to files, nor does an 
     1008implementation necessarily run on a system with a filesystem, however 
     1009for those implementations which do so it may be worth adding such a 
     1010note. 
     1011 
     1012A library file contains a single library.  A library named (A1 A2 AN) 
     1013is in a file named "A1/A2/AN.sld" ("sld" for "Scheme Library 
     1014Definition" or some other standardized file extension), relative to 
     1015some "library path".  For portability, library component names should 
     1016be integers or lower-case identifiers that avoid certain prohibited 
     1017characters.  When a library or top-level imports some other library, 
     1018the corresponding file is found in the obvious way. 
     1019 
     1020Alternately, this can be left entirely to WG2 and/or packaging systems 
     1021such as Snow. 
     1022 
     1023Vote `yes` to add such a note or `no` to leave it out. 
     1024 
     1025  * '''Options:''' yes, no, undecided 
     1026  * '''Default:''' no 
     1027  * '''Preferences:'''  
     1028 
     1029=== #341 Permit ambiguous imports of identifiers which are never used === 
     1030 
     1031It is currently an error to attempt to import the same identifier from more 
     1032than one library into another library or a top-level program, even if the identifier is not 
     1033used anywhere in the new library or program.  That requires programmers to make an 
     1034arbitrary decision to exclude it from one library or the other. 
     1035 
     1036Vote `yes` to agree with this proposal to require that, within a 
     1037single static library (not with the environment procedure where any 
     1038identifier may be subsequently used), an implementation must allow 
     1039such multiple imports if the identifier is not referenced and does not 
     1040occur in a syntax-rules template (which introduces conflicts with 
     1041low-level macros introduced by WG2). 
     1042 
     1043  * '''Options:''' yes, no, undecided 
     1044  * '''Default:''' no 
     1045  * '''Preferences:'''  
     1046 
     1047=== #342 Have READ-BYTEVECTOR(!) return 0 at EOF === 
     1048 
     1049Currently, `read-bytevector` and `read-bytevector!` return an EOF 
     1050object at EOF; otherwise, `read-bytevector` returns a non-empty 
     1051bytevector and `read-bytevector!` returns the number of bytes read. 
     1052Returning #u8() and 0, respectively, at EOF instead would make the 
     1053results always the same type.  This change would introduce the 
     1054ambiguity that one would not be able to detect EOF when reading a 
     1055bytevector of length 0 (which is to say, not reading any bytes at 
     1056all). 
     1057 
     1058Vote `zero` to return #u8() and 0 as in the proposal, and `eof-object` 
     1059to return the eof-object as in the current draft.  Vote `zero!` to 
     1060make the change only for `read-bytevector!`. 
     1061 
     1062  * '''Options:''' zero, eof-object, undecided 
     1063  * '''Default:''' eof-object 
     1064  * '''Preferences:'''  
     1065 
     1066=== #343 Editorial: divide domain explanations to be split before and after descriptions === 
     1067 
     1068All Scheme standards up to and including R6RS and R7RS draft-6 have 
     1069consistently placed the full domain at the beginning of each entry. 
     1070In most cases the domain consists only of the implicit type 
     1071restrictions from the prototype, but in some cases there are 
     1072additional domain restrictions that cannot be conveniently included in 
     1073the prototype such as the following `map` restrictions: 
     1074 
     1075  It is an error if ''proc'' does not accept as many arguments as 
     1076  there are ''lists'' and return a single value. 
     1077 
     1078It has been suggested to move this to an appropriate later point in the entry, 
     1079to put more emphasis on the initial entry description.  This has the 
     1080disadvantage of splitting the domain into two places, which can more 
     1081easily cause oversights and make quick domain confirmations difficult. 
     1082 
     1083An alternative is to separate the additional domain restrictions from 
     1084the initial description, as a separate short paragraph immediately 
     1085following the prototype and possibly de-emphasized by making it smaller. 
     1086his would keep the domain in one place and still allow 
     1087let the first line of the description stand out prominently in the 
     1088initial paragraph. 
     1089 
     1090Vote `start` for the status quo, `start-split` for the separate 
     1091de-emphasized option, or `later` to move additional restrictions to a 
     1092later point. 
     1093 
     1094  * '''Options:''' start, start-split, later, undecided 
     1095  * '''Default:''' start 
     1096  * '''Preferences:'''  
     1097 
     1098=== #345 Should 0.0 and -0.0 be distinct in the sense of EQV? === 
     1099 
     1100Currently, the draft report implies that 0.0 and -0.0 must be the same 
     1101in the sense of `eqv?`, because `eqv?` defers to `=` for numbers 
     1102(with the possible exception of NaNs). 
     1103 
     1104Vote `same` for the status quo, `different` to change to "must be 
     1105different", or `unspecified` to change to "may be different". 
     1106 
     1107  * '''Options:''' same, different, unspecified, undecided 
     1108  * '''Default:''' same 
     1109  * '''Preferences:'''  
     1110 
     1111=== #349 Define exact integers to be at least 24 bits === 
     1112 
     1113Currently, R7RS (tracking R5RS) does not constrain the sizes of exact 
     1114integers beyond being required to represent the indices of strings, 
     1115vectors and bytevectors. 
     1116 
     1117R6RS requires systems to support "practically unlimited" size exact 
     1118integers.  It also requires that a subset of these exist, called 
     1119''fixnums'', which must support at least the range -2^23^ to 2^23^-1. 
     1120(All practical Schemes have larger ranges for their fixnums). 
     1121This proposal suggests that we adopt this range as 
     1122the minimum range of R7RS exact integers. 
     1123 
     1124The immediate issue here is that a library name may contain 
     1125(non-negative) exact integers as well as identifiers in R7RS.  For 
     1126such names to be portable, there must be a portable range of exact 
     1127integers. 
     1128 
     1129See FixnumInfo to see what 39 existing Schemes do. 
     1130 
     1131Vote `24` to require 24 bits of precision, `16` to require 16 bits of precision, 
     1132or `none` to leave this entirely unspecified. 
     1133 
     1134  * '''Options:''' 24, 16, none, undecided 
     1135  * '''Default:''' none 
     1136  * '''Preferences:'''  
     1137 
     1138=== #354 mutating exports === 
     1139 
     1140We define mutating imports to be an error, however 
     1141the standard currently says nothing about what 
     1142happens when an exported binding is mutated from 
     1143within the library where it's defined. 
     1144In many common library implementations there 
     1145will be no effect (i.e. the import effectively gets 
     1146a copy of the original), whereas in a namespace 
     1147based implementation the change will be reflected, 
     1148so a conservative approach is to add a note saying 
     1149the result is unspecified. 
     1150 
     1151Vote `shared` to force the binding to be shared 
     1152and the change reflected everywhere it's imported, 
     1153`separate` to force the binding to be separate, 
     1154`none` to make no comment, and `unspecified` 
     1155or `error` to add a clarification to the standard 
     1156to that effect. 
     1157 
     1158  * '''Options:''' shared, separate, none, unspecified, error, undecided 
     1159  * '''Default:''' none 
     1160  * '''Preferences:'''  
     1161 
     1162=== #358 change epoch of current-second === 
     1163 
     1164A formal comment has proposed changing the epoch of current-second to 
     11651970-01-01 00:00:00 TAI rather than 1970-01-01 00:00:10 TAI (00:00:00 
     1166UTC). 
     1167 
     1168The actual time systems are independent of an epoch - the epoch is 
     1169just convenient for computer systems. 
     1170 
     1171The UTC-centric epoch was chosen (despite the use of TAI time) mostly 
     1172because it is used in popular TAI times such as libtai and Olson's 
     1173time library. 
     1174 
     1175See http://lists.scheme-reports.org/pipermail/scheme-reports/2012-March/001943.html for more details. 
     1176 
     1177Vote `utc` for the current draft's start-of-1970-in-utc epoch, or 
     1178`tai` for the proposed start-of-1970-in-tai epoch. 
     1179 
     1180  * '''Options:''' utc, tai, undecided 
     1181  * '''Default:''' utc 
     1182  * '''Preferences:'''