Changes between Version 3 and Version 4 of WG1BallotRadul


Ignore:
Timestamp:
12/03/12 19:49:44 (4 years ago)
Author:
cowan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotRadul

    v3 v4  
     1= Notes about Results = 
    12 
    2  
    3 = Instructions = 
    4  
    5     * You may list as many of the options as you want in order of preference. 
    6     * Options are comma-delimited (ignoring space) and case-insensitive. 
    7     * You can pipe-delimit (|) options you want to give equal weight to. 
    8     * You may write in your own option if you announce it to the list first. 
    9     * You may specify a variant with option/variant, for example srfi-1/module to vote for srfi-1 but clarify it should be in a separate module. Please also include the srfi-1 option in this case. 
    10     * You can write a free-form rationale after the "preferences" line, 
    11     * module means "yes, but I want it in a separate module", 
    12     * wg2 means "no, but I think it should go in WG2". 
    13     * undecided means I want to discuss this issue further. 
    14     * Abstain on any item by leaving the preferences blank.  
    15  
    16 = WG1 Ballot Items To Finalize By July 31 = 
     3See [wiki:WG1BallotExplanation WG1BallotExplanation]. 
    174 
    185== WG1 - Core == 
     
    207=== #460 Semantics of `eqv?` === 
    218 
    22 Earlier we voted on #125, #229 and #345 separately without regard to 
    23 the formal semantics of `eqv?` from a top level.  We need to first 
    24 decide what the definition of `eqv?` is, and consider if there should 
    25 be any exception cases as a secondary effect. 
     9The semantics of `eqv?` are highly contended, and as a result we are 
     10bringing this up for a third and final vote. 
    2611 
    27 The debate is fundamentally one of whether we define `eqv?` in terms 
    28 of "operational equivalence" as in R6RS or a simpler rule 
    29 (e.g. resolve by `=`) as in earlier standards. 
     12The earlier votes on #125 (`eqv?` may not return true for procedures) 
     13and #229 (`eqv?` is unspecified for NaNs) were voted on and treated as 
     14orthogonal.  There have been no objections to these, and so the 
     15results still stand.  We're only focusing on the core `eqv?` semantics 
     16for inexact numbers. 
    3017 
    31 R2RS had the simplest historical rule which was simply to use `=`. 
    32  
    33 The term "operational equivalence" appears in R3RS but for numbers the 
    34 definition is the same as in R4RS and R5RS, which is `=` plus the same 
    35 exactness.  This is the `r5rs` option, with the "true" cases written formally as: 
     18This is fundamentally a tale of three equivalences: mathematical, 
     19operational, and representational. 
    3620 
    3721{{{ 
    38   The `eqv?` procedure returns #t if: 
     22Ultra-brief history: 
    3923 
    40   (1) obj1 and obj2 are both booleans and are the same according 
    41   to the `boolean=?` procedure. 
    42  
    43   (2) obj1 and obj2 are both symbols and are the same symbol 
    44   according to the `symbol=?` procedure. 
    45  
    46   (3) obj1 and obj2 are both numbers, have the same exactness, are 
    47   numerically equal (see `=`). 
    48  
    49   (4) obj1 and obj2 are both characters and are the same 
    50   character according to the `char=?` procedure. 
    51  
    52   (5) obj1 and obj2 are both the empty list. 
    53  
    54   (6) obj1 and obj2 are pairs, vectors, bytevectors, records, 
    55   or strings that denote the same location in the store. 
    56  
    57   (7) obj1 and obj2 are procedures whose location tags are equal. 
     24R2RS was purely mathematical, defining `eqv?` on numbers in terms of 
     25`=`.  R3RS defined a simple operational equivalence by distinguishing 
     26exact and inexact.  This was not a complete operational equivalence 
     27because R3RS already had multiple precisions and implicit NaNs and 
     28signed zeros.  R[45]RS dropped the discussion of operational 
     29equivalence but kept the exactness separate.  R6RS re-introduced the 
     30notion of operational equivalence, this time with a complete definition. 
     31The R7RS 7th draft introduced an incomplete notion of representational 
     32equivalence - two numbers are `eqv?` iff they have the same IEEE-style 
     33representation. 
    5834}}} 
    5935 
    60 Note that (7) is an exception case which will be decided 
    61 separately in #125.  Furthermore, an exception to make NaNs 
    62 unspecified regardless of the semantics here will be decided in 
    63 #229. 
     36For this final vote there are three proposals under consideration, 
     37corresponding to the complete forms of each equivalence.  Variations 
     38may be proposed and added if a suitable rationale is given. 
    6439 
    65 The `r6rs` vote replaces (3) with the following operational 
    66 equivalence semantics: 
     40The `r5rs` proposal follows R5RS exactly, in the spirit of 
     41mathematical equivalence (assuming exacts and inexacts are different 
     42types to begin with).  The advantage of this is it's very simple and 
     43it appeals to idealists - people who want to pretend that they are 
     44computing real mathematical values without such thing as NaNs or 
     45negative zeros.  The disadvantage of this is, as with most things that 
     46appeal to idealists, it does not match reality.  Our computers use 
     47crude hacks for efficiency, and even if someone manages to build an 
     48ideal Scheme, it will likely be impractical and most implementations 
     49will continue to use those hacks.  Moreover, mathematical equivalence 
     50is already available via the `=` procedure.  This is not a practical 
     51equivalence relation for a standard.  The text for the true case of 
     52`eqv?` for inexact numbers under `r5rs` is: 
     53 
     54{{{ 
     55  (3) obj1 and obj2 are both numbers, have the same exactness, and are 
     56  numerically equal (see `=`). 
     57}}} 
     58 
     59The `r6rs` proposal follows R6RS exactly in the spirit of operational 
     60equivalence (with a small correction to avoid making everything 
     61unspecified via NaN transitivity).  The advantages of this is that 
     62it's exactly what you want to distinguish if two values will always 
     63behave the same, for example for compiler optimizations or 
     64memoization.  The disadvantage is that the definition is complicated 
     65and difficult to nail down - it doesn't account for non-standard 
     66extensions an implementation may provide which could distinguish 
     67certain new values.  The `r6rs` text is: 
    6768 
    6869{{{ 
     
    7071  equal (see `=`) 
    7172 
    72   (3.2) obj1 and obj2 are both inexact numbers, are numerically 
    73   equal (see `=`), and yield the same results (in the sense of 
    74   `eqv?`) when passed as arguments to any other procedure that 
    75   can be defined as a finite composition of Scheme’s standard 
     73  (3.2) obj1 and obj2 are both inexact numbers, are numerically equal 
     74  (see `=`), and yield the same results (in the sense of `eqv?` and 
     75  excluding `+nan.0`) when passed as arguments to any other procedure 
     76  that can be defined as a finite composition of Scheme’s standard 
    7677  arithmetic procedures. 
    7778}}} 
    7879 
    79 where "standard arithmetic procedures" refers arguably to either 
    80 11.7 or 11.7.4.3.  For R7RS it would apply to the "Numbers" 
    81 section 6.2.6.  R6RS further adds an extra case which is not 
    82 applicable because we don't guarantee record-types are first-class 
    83 objects: 
    84  
    85 {{{ 
    86   (8) obj1 and obj2 are record-type descriptors that are 
    87   specified to be `eqv?` in library section on “Procedural 
    88   layer”. 
    89 }}} 
    90  
    91 The `r6rs/all` option changes (3.2) to a finite composition of 
    92 any of the implementations arithmetic procedures.  The intention 
    93 is that `decode-float` if provided could distinguish NaNs, but 
    94 something like `eq?` (which could distinguish the same bit 
    95 pattern in different locations) would not be considered 
    96 arithmetic and not apply.  This does leave the 
    97 definition "arithmetic" open to some interpretation. 
    98  
    99 In contrast to R6RS, R7RS does not require the full numeric tower. 
    100 This means that any definition of operational equivalence would render 
    101 many numbers unspecified from the perspective of the standard, yet 
    102 users could rely on consistency within their own implementation, and 
    103 broad agreement amongst most implementations which provide the full 
    104 tower. 
    105  
    106 Finally, the `same-bits` option replaces (3) with: 
     80Finally, the `representational` proposal is based on the previous 
     81`same-bits` in the spirit of representational equivalence.  Two 
     82numbers are `eqv?` if they are represented the same way.  This is 
     83potentially finer grained than operational equivalence - it may in 
     84fact make useless distinctions, but it is generally safer to 
     85over-distinguish than to under-distinguish.  The `representational` 
     86text is: 
    10787 
    10888{{{ 
     
    11090  equal (see `=`) 
    11191 
    112   (3.2) obj1 and obj2 are both inexact real numbers conforming to the 
    113   IEEE 754-2008 standard, and they have the same radix, 
    114   precision, maximum exponent, sign, exponent, and significand as 
    115   described in IEEE 754-2008 
     92  (3.2) obj1 and obj2 are both numbers of the same composite numeric 
     93  type, whose corresponding fields are all `eqv?` 
    11694 
    117   (3.3) obj1 and obj2 are both inexact real numbers, are not implemented using 
    118   IEEE 754-2008, and are numerically equal (see `=`) 
     95    * numbers in the style of the IEEE 754-2008 floating point 
     96      standard are considered composites of their radix, precision, 
     97      maximum exponent, sign, exponent, and significand 
    11998 
    120   (3.4) obj1 and obj2 are both complex numbers whose real and imaginary 
    121   parts are `eqv?` 
     99    * non-real complex numbers are composites of their real and 
     100      imaginary parts 
    122101}}} 
    123  
    124 Keep in mind the semantics of `eqv?` also affect `memv`, `assv` and 
    125 `case`. 
    126102 
    127103  * '''References:''' 
    128104    * [https://groups.google.com/d/msg/scheme-reports-wg1/BGvDFtD6A1M/5pHmfXHtvEIJ eqv? issues summarized] 
    129105    * [https://groups.google.com/d/msg/scheme-reports-wg1/2Nv6oIND8HI/Z2HXPQMNFooJ the history of eqv? on numbers] 
    130   * '''Options:''' r5rs, r6rs, r6rs/all, same-bits 
     106    * [http://lists.scheme-reports.org/pipermail/scheme-reports/2012-November/002914.html Weaver's objection] 
     107    * [http://www.math.purdue.edu/~lucier/r7rs-eqv-discuss Lucier on IEEE 754] 
     108  * '''Options:''' r5rs, r6rs, representational 
    131109  * '''Default:''' r5rs 
    132   * '''Preferences:''' same-bits, r5rs 
    133  
    134 === #229 eqv? and NaN === 
    135  
    136 As announced previously this is being re-opened due to incorrect 
    137 formulation in the previous ballot, and in response to formal comment 
    138 #423. 
    139  
    140 Regardless of the result of #460, the semantics implies that `eqv?` 
    141 return `#f` on comparing any two NaN objects.  It is reasonable to 
    142 want to consider any two NaNs as the "same" since they behave the same 
    143 under any operation, even though none of the results are `=`.  Moreover, 
    144 it is very common to use a shortcut `eq?` pointer comparison before 
    145 falling back on general `eqv?` logic.  In deference to this R6RS makes 
    146 an exception and allows the result to be unspecified, and we should 
    147 consider allowing this exception. 
    148  
    149 This proposal is only to allow an explicit exception to make 
    150 NaN comparisons unspecified, regardless of the semantics. 
    151 Vote `no-exception` (or anything other than `unspecified`) 
    152 to require NaN comparisons to follow directly from #460. 
    153  
    154 The default of `unspecified` still holds from the previous invalidated 
    155 ballot. 
    156  
    157   * '''Options:''' no-exception, unspecified, undecided 
    158   * '''Default:''' unspecified 
    159   * '''Preferences:''' no-exception 
    160  
    161 As I interpret same-bits, it would actually require eqv? to return 
    162 #t on two IEEE NaNs that did, in fact, have the same pattern of 
    163 bits.  This case satisfies all rationales I can think of for wanting 
    164 NaNs to compare eqv?. 
    165  
    166 === #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) === 
    167  
    168 Procedures are another case for contention with `eqv?`.  In R3RS, an 
    169 operational equivalence was defined for procedures, and this was 
    170 subsequently removed. 
    171  
    172 R6RS went the other direction and allowed the exact same procedure `x` 
    173 to return `#f` for `(eqv? x x)`, and R7RS currently reaffirms this. 
    174 The rationale behind this is for compiler optimizations such as 
    175 inlining local procedures, that is given: 
    176  
    177 {{{ 
    178 (let ((square (lambda (x) (* x x)))) 
    179   (eqv? square square)) 
    180 }}} 
    181  
    182 it is reasonable for a compiler to perform the optimization: 
    183  
    184 {{{ 
    185 (eqv? (lambda (x) (* x x)) (lambda (x) (* x x))) 
    186 }}} 
    187  
    188 in which case the result would naturally return `#f`. 
    189  
    190 Vote `yes` to allow the result to be `#f`. 
    191  
    192 The default of `yes` still holds from the previous invalidated ballot. 
    193  
    194   * '''Options:''' yes, no, undecided 
    195   * '''Default:''' yes 
    196   * '''Preferences:''' no 
    197  
    198 I have argued against this on the list in the past, as being the 
    199 beginning of a slippery slope that has no end.  It occurs to me now 
    200 that procedures-with-locations are definable from 
    201 procedures-without-locations if the implementation supports 
    202 apply-hooks and gensyms (the latter of which I expect that most 
    203 implementations will have to, in one or another form, if nothing 
    204 else because cons is generative).  This means that a complete, 
    205 performance-conscious implementation should offer both tagged 
    206 procedures and untagged procedures, and the question becomes which 
    207 one should you get when you type "lambda" into the initial 
    208 environment.  I vote for retaining the invariant that for any 
    209 variable x, (eqv? x x) is true unless one is using an implementation 
    210 extension (like said untagged procedures).  (My understanding of my 
    211 votes on 460 and 229 implies this will be the case for NaNs also, 
    212 making that invariant complete.) 
    213  
    214 === #393 Defining record equality === 
    215  
    216 Currently, R7RS-small says that when `equal?` is applied to records 
    217 that are not `eqv?` (that were constructed by different calls to the 
    218 record constructor), the result may be `#t` or `#f` at the 
    219 implementation's discretion.  The proposal is to treat records of the same 
    220 type like pairs, strings, vectors, and bytevectors: that is, their 
    221 contents are recursively compared. 
    222  
    223 Vote `recursive` to require recursive comparison of the record's 
    224 fields, `identity` to return `#t` iff `eqv?` does, and `unspecified` 
    225 to leave this open. 
    226  
    227 Note `equal?` is already required to handle cycles regardless. 
    228  
    229   * '''Options:''' recursive, identity, unspecified, undecided 
    230   * '''Default:''' unspecified 
    231   * '''Preferences:''' unspecified 
    232  
    233 I don't think WG1 is in a position to solve this problem.  If equal? 
    234 is recursive, it becomes impossible to use records for information 
    235 hiding or security.  If equal? is identity, the common (at least in 
    236 my code, and in what I understand to be good style) case (of records 
    237 just being transparent immutable named tuples) breaks.  In either 
    238 case, the essential problem is that if you want the non-default 
    239 behavior for a particular record type, there is no way to 
    240 effectively modify equal?, without rewriting it and rewriting every 
    241 procedure that uses equal? internally (member comes to mind; even if 
    242 there are no others in the standard, there will be others in 
    243 libraries).  So the "right answer" to this involves some kind of 
    244 extensible or generic operation system, which we are by consensus 
    245 not in a position to produce.  The conservative option is 
    246 "unspecified". 
    247  
    248 === #306 What does "full Unicode" support mean in Appendix B? === 
    249  
    250 Specifically, does it indicate case-folding and normalization support 
    251 for the repertoire of any particular version of Unicode, or any 
    252 version greater than 5 or 6 or 6.1, or no particular version? 
    253  
    254 Full unicode refers to the set of characters available.  Case-folding 
    255 and character predicates are required to work according to the Unicode 
    256 standard for all supported characters.  The question of which version 
    257 of Unicode the property refers to is important.  We could require a 
    258 specific version (and all further revisions), or always require the 
    259 latest official Unicode standard, in which case an implementation 
    260 would not be compliant until it was updated with each new standard.  Alternatively, we could parameterize the feature identifier, so that implementations might claim to support (full-unicode 6), (full-unicode 6.1), etc. 
    261  
    262   * '''Options:''' at-least-6, at-least-6.1, latest, parameterize, undecided, unspecified 
    263   * '''Default:''' unspecified 
    264   * '''Preferences:'''  
    265  
    266 === #458 Remove the formal semantics from the report === 
    267  
    268 There have been a bunch of complaints about the formal semantics: it's 
    269 incomplete, it cannot be mechanized with a proof assistant, it doesn't 
    270 help either users or implementers very much, and so on.  See in 
    271 particular #453. 
    272  
    273 The semantics have been updated to include `dynamic-wind`, however the 
    274 other arguments still hold. 
    275  
    276 This proposal is to remove it from the report altogether, and to urge 
    277 the Steering Committee to create a new WG to produce one, likely in a 
    278 "rolling" style with increasingly comprehensive releases, on its own 
    279 schedule.  Some members of the current WG have expressed interest in 
    280 serving on such a group, and others have expressed their complete lack 
    281 of interest, so a new WG seems the best choice if this is done. 
    282  
    283 Alternately, we can adapt the operational semantics from R6RS. 
    284  
    285   * '''Options:''' remove, keep, operational, undecided 
    286   * '''Default:''' keep 
    287   * '''Preferences:'''  
    288  
    289 === #398 Allow repeated keys in `case` === 
    290  
    291 R5RS says it's an error for a key to appear in more than one clause of 
    292 `case` (or twice in the same clause, but that's trivial).  R6RS allows 
    293 the same key to appear more than one clause, but insists on 
    294 left-to-right testing throughout, like `cond`.  The R6RS editors 
    295 thought this was better for machine-generated code, though worse for 
    296 hand-written code. 
    297  
    298 The proposal is a compromise: allow keys to appear in more than one clause, 
    299 but behave as if the key appeared only in the first (leftmost) clause. 
    300 This allows hash-table or other non-left-to-right implementations. 
    301  
    302   * '''Options:''' r5rs, r6rs, leftmost, unspecified, undecided 
    303   * '''Default:''' r5rs 
    304   * '''Preferences:''' leftmost 
    305  
    306 === #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? 
    307  
    308 Following exactly in the footsteps of R6RS we voted for a `blob` API 
    309 and then changed the name to `bytevector`. 
    310  
    311 Formal comment #435 argues that `u8vector` is in more common use, so 
    312 this item is being re-opened.  The default is the current draft 
    313 `bytevector`, and for any member leaving the preferences are left 
    314 blank their votes from ballot 3 will be used. 
    315  
    316   * '''Options:''' blob, bytevector, byte-vector, u8vector, octet-vector, undecided 
    317   * '''Default:''' bytevector 
    318   * '''Preferences:'''  
    319  
    320 == WG1 - Library System == 
    321  
    322 === #353 No use before import in libraries === 
    323  
    324 For ease of implementation, the proposal is to make it an error for an 
    325 imported identifier to be referenced or defined in a library before 
    326 the library declaration that imports it.  This allows strict 
    327 left-to-right processing of library declarations, with no need to 
    328 delay processing till the end of the library. 
    329  
    330 Therefore, this would be an error (but still permitted as an extension 
    331 in Schemes that can easily provide it): 
    332  
    333 {{{ 
    334 (module 
    335   (begin (define x y)) 
    336   (import (library defining y)) 
    337 }}} 
    338  
    339 This would necessitate replacing the penultimate paragraph of section 
    340 5.5.1 with: 
    341  
    342 One possible implementation of libraries is as follows: After all 
    343 `cond-expand` library declarations are expanded, a new environment is 
    344 constructed for the library consisting of all imported bindings. The 
    345 expressions and declarations from all `begin`, `include`, and 
    346 `include-ci` declarations are expanded in that environment in the 
    347 order in which they occur in the library declaration.  Alternatively, 
    348 `cond-expand` and `import` declarations may be processed in left to 
    349 right order interspersed with the processing of expressions and 
    350 declarations, with the environment growing as imported bindings are 
    351 added to it by each `import` declaration. 
    352  
    353 Vote `yes` to add the restriction, or `no` to leave it out. 
    354  
    355   * '''Options:''' yes, no, undecided 
    356   * '''Default:''' no 
    357   * '''Preferences:'''  
    358  
    359 === #359 Limit numbers used in library names === 
    360  
    361 This is a proposal to limit numbers in library names to the range 0 to 
    362 32767.  Currently, there is no portable lower bound which all Schemes 
    363 can assume as the maximum size of an integer. 
    364  
    365 Numbers are mostly used for SRFI-based libraries anyway, which are not 
    366 likely to reach either limit. 
    367  
    368 The option `uint15` for the proposal as stated (0 to 32767), `int16` 
    369 for -32768 to 32767, int24 for -2^23^ to 2^23^-1, etc. 
    370  
    371 Vote `unspecified` to make no explicit requirement on the integers 
    372 allowed in library names. 
    373  
    374   * '''Options:''' uint15, int16, uint16, int24, uint24, unspecified, undecided 
    375   * '''Default:''' unspecified 
    376   * '''Preferences:''' uint15, uint16, unspecified 
    377  
    378 === #441 Make sure a program/library loads any imported libraries at most once === 
    379  
    380 Add the following text to the discussion of library loading: 
    381  
    382  Regardless of the number of times that a library is loaded, each 
    383  program or library that imports bindings from a library will receive 
    384  bindings from a single loading of that library, regardless of the 
    385  number of `import` or `cond-expand` declarations in which it appears. 
    386  
    387 to make it clear that, for example, 
    388  
    389 {{{ 
    390 (import (prefix (foo) 'foo:)) 
    391 (import (only (foo) bar)) 
    392 }}} 
    393  
    394 will cause `bar` and `foo:bar` to come from the same instantiation of 
    395 the library '(foo)' 
    396  
    397 Vote `yes` to add this requirement. 
    398  
    399   * '''Options:''' yes, no, unspecified, undecided 
    400   * '''Default:''' unspecified 
    401   * '''Preferences:''' yes, unspecified 
    402  
    403 === #402 Add an export-all form. === 
    404  
    405 Add an export-all form to the library declaration that means "export 
    406 all identifiers that are defined in the library with begin, include, 
    407 and include-ci but none that are imported with import." 
    408  
    409   * '''Options:''' yes, no, undecided 
    410   * '''Default:''' no 
    411   * '''Preferences:''' yes 
    412  
    413 This is definitely going to be the common case. 
    414  
    415 === #448 Add library declaration include-library-declarations === 
    416  
    417 The proposed `include-library-declarations` allows a library to 
    418 incorporate a file containing arbitrary library declarations, not just 
    419 Scheme code (definitions and expressions).  This allows, for example, 
    420 the exports of a module to be written directly in the library file, 
    421 and its imports in a separate file. 
    422  
    423 An alternative would be something like `(export-from <library>)` to 
    424 export the same bindings as another library.  This does require the 
    425 clumsiness of actually defining the identifiers in the other library 
    426 if it is abstract. 
    427  
    428   * '''Options:''' include-library-declarations, export-from, no, undecided 
    429   * '''Default:''' no 
    430   * '''Preferences:''' undecided 
    431  
    432 === #449 Clarify library loading rules === 
    433  
    434 R7RS currently says: 
    435  
    436  Within a program, each imported library is loaded at least once, and, 
    437  if imported by more than one program or library, may possibly be 
    438  loaded additional times. 
    439  
    440 Richard Kelsey thinks this is too liberal, and proposes: 
    441  
    442  Regardless of the number of times that a library is loaded, each 
    443  program or library that imports bindings from a library will receive 
    444  bindings from a single loading of that library, regardless of the 
    445  number of `import` or `cond-expand` forms in which it appears. 
    446  
    447 Aaron Hsu, however, thinks this is too restrictive, and proposes 
    448 (backed up by actual R6RS implementations): 
    449  
    450  If a library's definitions are referenced in the expanded form of a 
    451  program or library body, then that library must be loaded before the 
    452  expanded program or library body is evaluated. This rule applies 
    453  transitively. 
    454  
    455  Similarly, during the expansion of a library, if a syntax keyword 
    456  imported from a library is needed to expand the library, then the 
    457  imported library must be visited before the expansion of the 
    458  importing library. 
    459  
    460   * '''Proposals:''' 
    461     * '''one:''' Kelsey's proposal 
    462     * '''one-or-more:''' current draft 
    463     * '''zero-or-more:''' Hsu's proposal, R6RS status-quo 
    464     * '''zero-or-one:''' Kelsey's proposal with Hsu's relaxation 
    465   * '''Options:''' one, one-or-more, zero-or-one, zero-or-more 
    466   * '''Default:''' one-or-more 
    467   * '''Preferences:''' one 
    468  
    469 == WG1 - Numerics == 
    470  
    471 === #366 Add (log z b) for logarithm of z to the base b === 
    472  
    473 Coverage for this R6RS feature is currently sparse: only Gauche, Chez, 
    474 Vicare, Larceny, Ypsilon, Mosh, !IronScheme, KSi, RScheme, Rep support 
    475 it.  But it is convenient when working in bases other than ''e'' such 
    476 as 10, 2, or 16, and it is just a few extra lines of code, since `(log 
    477 z b)` => `(/ (log z) (log b))` for arbitrary complex numbers ''z, b''. 
    478  
    479 Vote `yes` to add the optional second argument from R6RS. 
    480  
    481   * '''Options:''' yes, no, undecided 
    482   * '''Default:''' no 
    483   * '''Preferences:''' 
    484  
    485 === #367 Inexact division by exact zero === 
    486  
    487 Draft 6 says that it's an error for an argument of `/` (other than the 
    488 first) to be an exact zero.  R6RS, however, says that it's an error 
    489 only if ''all'' the arguments are exact.  In other words, `(/ 2.0 0)` 
    490 is an error according to the draft, but in R6RS it returns `+inf.0` 
    491 (assuming the implementation supports it).  The proposal is to adopt 
    492 the R6RS wording. 
    493  
    494 Cowan tested `(/ 2.0 0)` in the usual set of Schemes: 
    495  
    496  * Racket, Gambit, Chicken (with the numbers egg), Guile, Chibi, Elk, Spark report an error. 
    497  * Gauche, Bigloo, Scheme48/scsh, Kawa, SISC, Chez, SCM, !Ikarus/Vicare, Larceny, Ypsilon, Mosh, !IronScheme, NexJ, STklos, RScheme, BDC, UMB, VX return `+inf.0`. 
    498  * MIT, scsh, Shoe, !TinyScheme, Scheme 7, XLisp, Rep, Schemik, Inlab always report an error when dividing by zero, exact or inexact. 
    499  * KSi, Scheme 9 produce incorrect results. 
    500  * !SigScheme, Dream, Oaklisp, Owl Lisp don't support inexact numbers. 
    501  
    502 Vote `error` for the current draft semantics that it is an error, 
    503 `all-error` for the R6RS semantics that it is only an error if all 
    504 arguments are exact, or `unspecified` to make this case unspecified. 
    505  
    506   * '''Options:''' error, all-error, unspecified, undecided 
    507   * '''Default:''' error 
    508   * '''Preferences:''' error, unspecified 
    509  
    510 === #369 Require that - and / allow an arbitrary number of arguments === 
    511  
    512 R5RS requires that `-` and `/` accept one or two arguments, and labels 
    513 support for more than two as "optional".  R6RS requires such support. 
    514 The proposal is to require it. 
    515  
    516 All Schemes in the test suite support more than two arguments except 
    517 Scheme48/scsh.  (Owl Lisp does not support variadic procedures of any 
    518 kind.) 
    519  
    520 Vote `require` for required n-ary behavior and `optional` to leave it 
    521 optional as in R5RS.  Alternately, vote `forbidden` to make this 
    522 always an error in all implementations. 
    523  
    524   * '''Options:''' required, optional, forbidden, undecided 
    525   * '''Default:''' optional 
    526   * '''Preferences:''' required 
    527  
    528 Since everybody does it anyway, might as well allow code to depend 
    529 on it.  Not that (/ 1 2 3 4) is very intuitive. 
    530  
    531 === #370 Log of exact and inexact zero === 
    532  
    533 R5RS and draft 6 of R7RS don't say what `(log 0.0)` and `(log 0)` 
    534 return.  R6RS requires `-inf.0` and an exception respectively.  The 
    535 proposal is to say that `(log 0.0)` returns `-inf.0` on systems that 
    536 have `-inf.0`, and that `(log 0)` is an error. 
    537  
    538 In Racket, Gambit, Chicken (with the numbers egg), Guile, Chibi, Chez, 
    539 !Ikarus/Vicare, Larceny, Ypsilon, Mosh, !IronScheme, STklos, Spark, 
    540 `(log 0.0)` returns `-inf.0` and `(log 0)` raises an exception. 
    541  
    542 Gauche, MIT, Chicken (without the numbers egg), Bigloo, Scheme48/scsh, 
    543 Kawa, SISC, SCM, NexJ, KSi, RScheme, XLisp, Rep, VX, SXM, Inlab return 
    544 `-inf.0` in both cases. 
    545  
    546 Elk, UMB, Oaklisp raise an exception in both cases. 
    547  
    548 Scheme 7 returns the wrong answer in both cases. 
    549  
    550 !SigScheme, Shoe, !TinyScheme, Dream, BDC, Owl Lisp don't support `log`. 
    551  
    552 Scheme 9 apparently goes into an infinite loop in both cases. 
    553  
    554 Vote `r6rs` for the R6RS behavior of returning `-inf.0` and raising an 
    555 error, respectively.  Vote `infinity` to always return `-inf.0`. 
    556  
    557   * '''Options:''' r6rs, infinity, unspecified, undecided 
    558   * '''Default:''' unspecified 
    559   * '''Preferences:'''  
    560  
    561 === #407 Dividing exact 0 by an inexact number === 
    562  
    563 This proposal allows `(/ 0 `''x''`)`, where ''x'' is an inexact 
    564 number, to return an exact value.  Currently only Racket, Gambit, 
    565 !TinyScheme, Sizzle, Spark do this; see [wiki:Zero Zero] for details. 
    566  
    567 Vote `zero` to allow (but not require) this to return exact 0.  Vote 
    568 `no-nan` to allow it to return 0 except when `x` is `+nan.0`, where it 
    569 would return `+nan.0`. 
    570  
    571   * '''Options:''' zero, no-nan, unspecified, undecided 
    572   * '''Default:''' unspecified 
    573   * '''Preferences:''' zero 
    574  
    575 While this does have the downside of potentially masking a NaN, it 
    576 only masks one in a computation whose result wasn't going to be used 
    577 anyway.  If the programmer really did not want their NaNs masked, 
    578 they could have ensured the zero were inexact.  In the meantime, 
    579 this allows an optimization, which can be very important in numeric 
    580 code because it can chain. 
    581  
    582 === #410 Infinity vs. NaN in max and min === 
    583  
    584 Currently R7RS says nothing about the value of `(max +inf.0 +nan.0)` 
    585 or `(min -inf.0 +nan.0)`.  R6RS required these functions to return the 
    586 infinite value, but this was adopted by some but not all R6RS 
    587 implementations (see MaxInfNan for details).  R5RS implementations are 
    588 also divided. 
    589  
    590 The proposal is to allow R7RS implementations to provide either value. 
    591  
    592 Vote `both` to explicitly add a note that either are allowed, 
    593 `infinity` to require the infinite value as in R6RS, `nan` to require 
    594 returning `+nan.0`, and `unspecified` leave unspecified (i.e. the same 
    595 as `both` but without the note). 
    596  
    597   * '''Options:''' both, infinity, nan, unspecified, undecided 
    598   * '''Default:''' unspecified 
    599   * '''Preferences:''' unspecified 
    600  
    601 === #395 Infinite and NaN complex numbers === 
    602  
    603 Currently both `infinite?` and `nan?` return `#t` to a complex number 
    604 like `+inf.0+nan.0i`.  Is this the Right Thing, or should `infinite?` 
    605 only return `#t` if neither part is a NaN? 
    606  
    607 Note it is reasonable for an implementation to not support partial nan 
    608 complex numbers. 
    609  
    610 Vote `disjoint` to ensure that `infinite?` and `nan?` are disjoint 
    611 predicates as in the proposal, or `overlap` to allow the current 
    612 behavior. 
    613  
    614   * '''Options:''' overlap, disjoint, unspecified, undecided 
    615   * '''Default:''' overlap 
    616   * '''Preferences:''' disjoint 
    617  
    618 === #364 truncate, floor, ceiling round should return a non-finite argument === 
    619  
    620 Currently R7RS is silent on what truncate, floor, ceiling, and round 
    621 do when the argument is `+inf.0`, `-inf.0`, or `+nan.0`. R6RS has them 
    622 return the argument, which seems reasonable. 
    623  
    624 Tests were made for `(round (* 1.0e200 1.0e200))` on a variety of 
    625 implementations. 
    626  
    627 Racket, Gauche, Chicken (with and without the numbers egg), Bigloo, 
    628 Guile, Kawa, Chibi, Chez, SCM, Ikarus/Vicare?, Larceny, Ypsilon, Mosh, 
    629 IronScheme, !NexJ, STklos, KSi, Shoe, BDC, Rep, Schemik, Elk, Spark 
    630 all return the argument. 
    631  
    632 MIT, Gambit, Scheme48/scsh, SISC, Scheme 9, Scheme 7, signal errors. 
    633  
    634 SigScheme, TinyScheme, Dream, UMB don't work for one or another 
    635 reason. 
    636  
    637 Oaklisp and Owl Lisp don't do flonums. 
    638  
    639 XLisp only has fixnums and flonums, and returns the largest or 
    640 smallest fixnum as the case may be. 
    641  
    642 RScheme returns a variety of slightly strange values: (round +inf.0), 
    643 for example, is 0, but (round -inf.0) is -inf.0. 
    644  
    645 Vote `input` to return the input, `error` to specify "it is an error", 
    646 and `unspecified` to leave unspecified as in the current draft. 
    647  
    648   * '''Options:''' input, error, unspecified, undecided 
    649   * '''Default:''' unspecified 
    650   * '''Preferences:''' input 
    651  
    652 === #392 Exact positive and non-negative integer predicates === 
    653  
    654 There are two useful subsets of the exact numbers, both of which are 
    655 commonly called natural numbers, depending on who's talking. 
    656 Logicians, set theorists, and computer scientists include 0, other 
    657 mathematicians mostly don't.  This proposal adds the predicates 
    658 `exact-positive-integer?` and `exact-non-negative-integer?`, analogous 
    659 to `exact-integer?`.  Because of the ambiguity, the name 
    660 `natural-number?` is not proposed. 
    661  
    662 Vote `yes` to add these two procedures. 
    663  
    664   * '''Options:''' yes, no, wg2, undecided 
    665   * '''Default:''' no 
    666   * '''Preferences:'''  
    667  
    668 == WG1 - Read/Write == 
    669  
    670 === #380 Is support of TAB as a whitespace character required or not? === 
    671  
    672 2.2 says: 
    673  
    674 Whitespace characters include the space and newline characters. 
    675 (Implementations may provide additional whitespace characters such as 
    676 tab or page break.) 
    677  
    678 However, 7.1.1 has: 
    679  
    680 <intraline whitespace> -> <space or tab> 
    681 <whitespace> -> <intraline whitespace> | <newline> | <return> 
    682  
    683 So 2.2 implies that supporting tabs is allowed but not required, yet 
    684 7.1.1 implies supporting tabs is required. 
    685  
    686 Vote `required` to require support for tab as a whitespace character 
    687 by `read`.  `char-whitespace?` is required to return `#t` for it 
    688 regardless. 
    689  
    690   * '''Options:''' required, optional, undecided 
    691   * '''Default:''' optional 
    692   * '''Preferences:''' required 
    693  
    694 === #388 Specify what `display` does with circular lists === 
    695  
    696 Currently we don't specify what `display` does with circular lists. 
    697 Should it generate labels like `write`, or loop like `write-simple`, 
    698 or leave it unspecified? 
    699  
    700   * '''Options:''' labels, loop, unspecified 
    701   * '''Default:''' unspecified 
    702   * '''Preferences:'''  
    703  
    704 === #447 #!fold-case and #!no-fold-case have no final delimiter === 
    705  
    706 The `#!fold-case` and `#!no-fold-case` directives are read as 
    707 comments, which means that they are treated as whitespace (section 
    708 2.2).  Unlike the other kinds of comments, their final delimiter is 
    709 implicit.  This means that `(1#!no-fold-cases)` reads as `(1 s)`. 
    710 This seems unfortunate. 
    711  
    712   * '''Proposals:'''  
    713     * '''identifier:''' add the formal syntax `<lexical-directive> --> #! <identifier>` and then make the interpretation of `<identifier>` implementation-dependent, except for the standard cases `#!fold-case` and `#!no-fold-case`. (Per Bothner, Richard Kelsey) 
    714     * '''delimiter:''' the directives must be followed by delimiter (John Cowan) 
    715     * '''comment:''' the draft status-quo 
    716   * '''Options:''' identifier, delimiter, comment, undecided 
    717   * '''Default:''' comment 
    718   * '''Preferences:'''  
    719  
    720 === #442 write procedure is not backwards compatible === 
    721  
    722 There is concern that the output of `write` cannot be read by non-R7RS 
    723 implementations.  This is not a strict requirement, but is reasonable 
    724 if using simple sexp-based file/interchange formats. 
    725  
    726 Specifically, even though there are no cycles in 
    727  
    728   `(let ((x (list 2))) (write (list x x)))` 
    729  
    730 it previously output "((2) (2))" but now outputs "(#0=(2) #0#)". 
    731  
    732 The WG concern is that R5RS write is unsafe, easily causing infinite 
    733 loops, and should therefore not be the default.  Thus we renamed this 
    734 "write-simple", requiring programmers to know they are writing a 
    735 "simple" data structure up front. 
    736  
    737 Arguably, there are three procedures desired: 
    738  
    739   * write-cyclic: uses labels only to avoid cycles 
    740   * write-shared: uses labels for all shared structure 
    741   * write-simple: won't use labels - it is an error to pass a cyclic structure 
    742  
    743 although even for `write-shared` people sometimes want to treat 
    744 containers such as strings separately. 
    745  
    746 Note the algorithms for detecting shared structure differ from those 
    747 for detecting cycles, so providing both -shared and -cyclic imposes an 
    748 additional implementation burden. 
    749  
    750   * '''Proposals:''' 
    751     * '''write+simple:''' the current draft status quo 
    752     * '''write+shared:''' change `write` back and add `write-shared` to explicitly handle sharing 
    753     * '''write+cyclic:''' change `write` back and add `write-cyclic` to handle only cycles 
    754     * '''write+shared+cyclic:''' change `write` back and add both `write-shared` and `write-cyclic` 
    755     * '''write+simple+shared:''' `write` handles cycles only, provide `write-simple` and `write-shared` separately 
    756   * '''Options:''' write+simple, write+shared, write+cyclic, write+shared+cyclic, write+simple+shared, unspecified, undecided 
    757   * '''Default:''' write+simple 
    758   * '''Preferences:''' write+simple 
    759  
    760 If you are trying to use read/write to implement serialization and 
    761 you have two different implementations of Scheme, one of which 
    762 writes shared structure by default and the other does not read it, 
    763 you have two perfectly good options: Either write a procedure that 
    764 unshares shared structure, or implement reading of shared structure. 
    765 The latter is harder, but is likely to yield a more compact external 
    766 representation. 
    767  
    768 === #219 Bring back readable boolean literals === 
    769  
    770 Scheme used to use `#!true` and `#!false` before abbreviating to 
    771 the `#t` and `#f` syntax. 
    772  
    773 In draft 4 we added these back in as aliases, without the "!" now 
    774 that tokens are required to be delimited so there would be no ambiguity. 
    775  
    776 Some objections were made to the new syntax which generated 
    777 a lot of discussion, so we are re-opening this ticket.  The default 
    778 is the previous decision to add `#true` and `#false` as aliases. 
    779  
    780 The primary objection is that boolean literals are very common, 
    781 and this introduces needless incompatibilities with non-R7RS 
    782 systems, and potential confusion in documentation. 
    783  
    784 The counter-argument is that these are more readable and 
    785 friendly to beginners, and allow easy visual distinction in long lists 
    786 of booleans.  We retain full backwards compatibility and are 
    787 under no obligation for non-R7RS systems to be able to run R7RS code. 
    788  
    789 Note that Racket and Chibi independently adopted this same 
    790 syntax unaware of each other.  Chicken also supports this via 
    791 its SRFI-38 implementation. 
    792  
    793   * '''References:''' 
    794   * '''Proposals:''' 
    795      * '''long:''' #true and #false 
    796      * '''bang-long:''' #!true and #!false 
    797   * '''Options:''' long, bang-long, none, undecided 
    798   * '''Default:''' long 
    799   * '''Preferences:''' long 
    800  
    801 === #443 Recommend sources of character names === 
    802  
    803 Currently, we allow implementations to provide their own names for 
    804 characters, but provide no guidance for them.  There are two plausible 
    805 sources: the [http://unicode.org/Public/UNIDATA/NamesList.txt names in 
    806 the Unicode Standard], and the [http://www.w3.org/TR/xml-entity-names/ 
    807 entity names specified by W3C] for use in HTML, MathML, and other 
    808 markup standards (ultimately derived from ISO SGML character entity 
    809 sets). 
    810  
    811 The Unicode names are in all upper case and contain significant spaces 
    812 and apostrophes as name characters, which would require some mapping 
    813 to make valid Scheme identifiers.  The W3C name list is incomplete 
    814 though fairly large (currently 2237 names), covering mainly the Greek 
    815 and Cyrillic scripts and non-ASCII punctuation and symbols.  It 
    816 distinguishes between iota (small) and Iota (capital). 
    817  
    818 Vote `w3c` for the W3C list, `unicode` to use the Unicode list with 
    819 names mapped by converting to lowercase and replacing any 
    820 non-identifier character (space and apostrophe) with hyphens.  Vote 
    821 `unspecified` to leave the character name extensions entirely up to 
    822 the implementation. 
    823  
    824   * '''Options:''' w3c, unicode, unspecified, undecided 
    825   * '''Default:''' unspecified 
    826   * '''Preferences:'''  
    827  
    828 == WG1 - Base Library == 
    829  
    830 === #140 Removing `quotient`, `remainder`, `modulo` === 
    831  
    832 With the acceptance of #278, we reduced the set of division operators 
    833 to `truncate-*` and `floor-*` and move these into the base library. 
    834 Three of these procedures are simply aliases for `quotient`, 
    835 `remainder` and `modulo`, so it is worth considering removing the old 
    836 names. 
    837  
    838 Since the old names are in IEEE Scheme we need strong justification 
    839 for removing them from (scheme base), and even if we do so they will 
    840 remain available in (scheme r5rs). 
    841  
    842 We have precedence for changing names, but only in the case when the 
    843 existing names were both actively misleading and had already been 
    844 changed in R6RS.  Specifically, in ticket #328 we replaced the names 
    845 `inexact->exact` and `exact->inexact` with the more accurate `exact` 
    846 and `inexact`. 
    847  
    848 Arguably the new division operator names are clearer, but the old 
    849 names are not actually misleading. 
    850  
    851 Vote `yes` to remove the old names from (scheme base), or `no` to 
    852 leave them in as aliases. 
    853  
    854   * '''Options:''' yes, no, undecided 
    855   * '''Default:''' no 
    856   * '''Preferences:''' no 
    857  
    858 === #378 Rename GET-FEATURES to just FEATURES === 
    859  
    860 This is compatible with Chicken, and "more Scheme-like, less 
    861 Java-like".  Okay, it's bikeshedding. 
    862  
    863   * '''Options:''' features, get-features, undecided 
    864   * '''Default:''' get-features 
    865   * '''Preferences:''' features 
    866  
    867 === #384 Merge `bytevector-copy` and `bytevector-copy-partial` === 
    868  
    869 Under this proposal, the name would be `bytevector-copy` and the 
    870 signature would be 
    871  
    872   `(bytevector-copy `''bytevector'' [''start'' [''end'']]`)` 
    873  
    874 Vote `yes` for this simplification. 
    875  
    876   * '''Options:''' yes, no, undecided 
    877   * '''Default:''' no 
    878   * '''Preferences:'''  
    879  
    880 === #385 Merge `write-bytevector` and `write-bytevector-partial` === 
    881  
    882 One proposal is `port-last` with a signature of: 
    883  
    884   `(write-bytevector ''bytevector'' [''start'' [''end'' [''port'']]])` 
    885  
    886 This has the disadvantage of being required to call 
    887 `bytevector-length` when writing to a specific port. 
    888  
    889 Alternately we could do `offsets-last`: 
    890  
    891   `(write-bytevector ''bytevector'' [''port'' [''start'' [''end'']]])` 
    892  
    893 which has the disadvantage of separating the bytevector from its 
    894 offsets. 
    895  
    896 Alternately, vote `separate` to keep these as two separate procedures. 
    897  
    898   * '''Options:''' port-last, offsets-last, separate, undecided 
    899   * '''Default:''' separate 
    900   * '''Preferences:'''  
    901  
    902 === #387 Add start/end arguments to string->vector and vector->string === 
    903  
    904 This is a proposal to add optional start (inclusive) and end 
    905 (exclusive) arguments to `string->vector` and `vector->string`.  We 
    906 now have start (inclusive) and end (exclusive) arguments for 
    907 `string->list` and `vector->list`, but our non-R5RS and non-SRFI 
    908 procedures to convert directly between strings and vectors don't 
    909 provide these. 
    910  
    911 Vote `yes` to add these optional arguments. 
    912  
    913   * '''Options:''' yes, no, undecided 
    914   * '''Default:''' no 
    915   * '''Preferences:''' yes 
    916  
    917 === #391 Add predicates for R7RS signalled conditions === 
    918  
    919 R7RS requires an error to be signalled (which means an exception is 
    920 raised as if by `raise`) in the following circumstances: 
    921  
    922  1. Trying to open for input or delete a file that does not exist or is otherwise inaccessible. 
    923  1. Specifying an argument to `scheme-report-environment` that the implementation doesn't support.  (It must support 7 and may support other values.) 
    924  1. An EOF is encountered while `read` is in the middle of a datum. 
    925  1. Using `expt` to raise zero to the power of a non-real number (alternatively an arbitrary number may be returned). 
    926  
    927 This proposal is to provide four standard predicates that identify 
    928 these specific conditions, to be used in `guard` clauses or in 
    929 `with-exception` handlers as a portable means of detecting these 
    930 errors.  Although these predicates may return `#t` on other objects, 
    931 if one reports `#t` on an object, the others must report `#f`. 
    932 Proposed names are `file-error?`, `scheme-report-error?`, 
    933 `read-error?`, and `expt-error?` respectively. 
    934  
    935 Vote `yes` to add these procedures, or `file-only` to only add the 
    936 `file-error?` predicate. 
    937  
    938   * '''Options:''' yes, file-only, no, undecided 
    939   * '''Default:''' no 
    940   * '''Preferences:'''  
    941  
    942 === #400 Define record? . === 
    943  
    944 We should define the predicate record? so that it's possible to 
    945 distinguish instances of record types from all other types.  It should 
    946 not be necessary to enumerate all record type predicates in order to 
    947 determine whether an object is an instance of a record. 
    948  
    949 This is Alexey Radul's suggestion. 
    950  
    951   * '''Options:''' yes, no, undecided 
    952   * '''Default:''' no 
    953   * '''Preferences:'''  
    954  
    955 === #425 Add read-string, read-string!, write-string procedures to (scheme base) === 
    956  
    957 This was requested by Formal Comment #424. 
    958  
    959 These procedures would be provided for parallelism with the 
    960 byte-vector I/O operations: 
    961  
    962 ||Byte||Character||Bytevector||String|| 
    963 ||read-u8||read-char||read-bytevector(!)||read-string(!)|| 
    964 ||write-u8||write-char||write-bytevector||write-string|| 
    965  
    966 If #385 passes, optional ''start'' (inclusive) and ''end'' (exclusive) 
    967 index arguments would be added to `write-string`.  Otherwise 
    968 `write-partial-string` would be provided. 
    969  
    970 Vote `yes` to add all three, `immutable` to add only `read-string` and 
    971 `write-string`, or `no` to leave them out. 
    972  
    973   * '''Options:''' yes, immutable, no, undecided 
    974   * '''Default:''' no 
    975   * '''Preferences:'''  
    976  
    977 === #433 full conversion cycle for containers === 
    978  
    979 Marc Feeley proposes it should be possible to convert from any 
    980 container type to another, possibly via an intermediary such as 
    981  
    982   `(list->B (A->list a))` 
    983  
    984 proposing specifically "list" be the universally available 
    985 intermediary, although "vector" would also be worth considering. 
    986  
    987 The container types are list, vector, string and bytevector.  String 
    988 and bytevector are second-class in that they are not general-purpose 
    989 container types, and may raise errors converting from lists or 
    990 vectors. 
    991  
    992 Vote `list` for the proposal to add the following procedures to 
    993 complete the cycle: 
    994  
    995   * list->bytevector 
    996   * bytevector->list 
    997  
    998 Vote `vector` to add the equivalent procedures to allow converting 
    999 between any of the types and vectors, specifically the following two 
    1000 new procedures: 
    1001  
    1002   * vector->bytevector 
    1003   * bytevector->vector 
    1004  
    1005 Vote `list+vector` to add both list and vector conversions. 
    1006  
    1007 The `latin-1` proposal also adds the Latin-1-centric ideas of string to 
    1008 bytevector conversion, where each element of the bytevector is 
    1009 converted to/from a character with char->integer/integer->char. 
    1010  
    1011 The `matrix` proposal requires all 4^3^=64 conversions. 
    1012  
    1013   * '''Options:''' matrix, list, vector, list+vector, latin-1, no, undecided 
    1014   * '''Default:''' no 
    1015   * '''Preferences:'''  
    1016  
    1017 === #444 Add vector-append procedure === 
    1018  
    1019 This is for completeness with `append` and `string-append`.  See #436 
    1020 for the Formal Comment that triggered this ticket. 
    1021  
    1022   * '''Options:''' yes, no, undecided 
    1023   * '''Default:''' no 
    1024   * '''Preferences:'''  
    1025  
    1026 === #451 Add bytevector-append procedure === 
    1027  
    1028 This is for consistency with `append`, `string-append`, and 
    1029 `vector-append` (per ticket #444) procedures. 
    1030  
    1031   * '''Options:''' yes, no, undecided 
    1032   * '''Default:''' no 
    1033   * '''Preferences:'''  
    1034  
    1035 === #445 Bidirectional ports and port-open? === 
    1036  
    1037 Replace `port-open?` with `input-port-open?` and `output-port-open?`, 
    1038 since a bidirectional port can be closed on one side without the 
    1039 other.  See Formal Comment #439. 
    1040  
    1041 Vote `replace` to replace `port-open?` with just the two new versions, 
    1042 or `add` to have all three. 
    1043  
    1044   * '''Options:''' replace, add, no, undecided 
    1045   * '''Default:''' no 
    1046   * '''Preferences:'''  
    1047  
    1048 === #450 Eliminate default for fill argument in vector-copy === 
    1049  
    1050 Marc Feeley writes: 
    1051  
    1052 It is a bad idea for the ''fill'' parameter of `vector-copy` to have a 
    1053 default. When ''fill'' is absent, it should be an error when ''start'' 
    1054 and ''end'' are not within the bounds of the sequence. Otherwise, some 
    1055 index calculation errors (off-by-one on ''end'') may go 
    1056 unnoticed. Moreover, when it is supplied, ''fill'' should also be used 
    1057 when ''start'' is less than 0, for consistency with the case where 
    1058 ''end'' is greater to the length of the sequence. 
    1059  
    1060 Vote `required` to make the fill parameter required, `error` to make 
    1061 it an error in the case that fill is absent yet needed, `remove` to 
    1062 remove the fill parameter and signal a runtime error if end is longer 
    1063 than the input vector, or `default` for the current status quo. 
    1064  
    1065   * '''Options:''' required, error, remove, default, undecided 
    1066   * '''Default:''' default 
    1067   * '''Preferences:'''  
    1068  
    1069 === #404 Make handlers take a raise-continuable? argument. === 
    1070  
    1071 Pass exception handlers a second, Boolean argument that declares 
    1072 whether the exception is continuable. 
    1073  
    1074   * '''Options:''' yes, no, undecided 
    1075   * '''Default:''' no 
    1076   * '''Preferences:'''  
    1077  
    1078 === #464 Add optional start and end parameters to utf8->string and string->utf8. === 
    1079  
    1080 Per ticket 464, add optional start and end arguments to `utf8->string` 
    1081 and `string->utf8`. 
    1082  
    1083 Vote `both` to add optional start and end arguments to both, 
    1084 `string->utf8` or `utf8->string` to add them to only one procedure, or 
    1085 `neither` to leave both unchanged. 
    1086  
    1087   * '''Options:''' both, string->utf8, utf8->string, neither 
    1088   * '''Default:''' neither 
    1089   * '''Preferences:'''  
    1090  
    1091 == WG1 - Optional Libraries == 
    1092  
    1093 === #373 (exit #t) should be the same as (exit) === 
    1094  
    1095 See Formal Comment #372 for the argument.  Cowan writes: "I support this proposal.  I 
    1096 don't support the alternative proposal to just say that any true value 
    1097 reports success and only #f reports failure, for there is usually only 
    1098 one kind of success (0 on Posix and Windows, "" on Plan 9, 2 on VMS) 
    1099 and many kinds of failure." 
    1100  
    1101 It is reasonable and convenient to use `#t`/`#f` as generic 
    1102 success/failure for portable programs, with `(exit)` as a shorthand 
    1103 for the "normal" completion `(exit #t)`. 
    1104  
    1105 Another reasonable extension is fallback for certain success values 
    1106 that the implementation cannot understand.  Specifically, `0` is 
    1107 commonly used for success on Posix systems, and the empty string "" as 
    1108 success on Plan9.  We could require that if the implementation does 
    1109 not know how to pass these value types (string or number) to the OS, 
    1110 then it should recognize `0` and `""` as true.  Any value other than 
    1111 these which cannot be passed to the OS should be treated as a generic 
    1112 error.  That way, a program written for Posix that alternatively uses 
    1113 `(exit 0)` and `(exit <n>)` will still work as desired on a Plan9 
    1114 system, only losing details of the type of failure (and likewise for 
    1115 Plan9 programs running on Posix). 
    1116  
    1117 In either case, unless someone makes a proposal to the contrary, 
    1118 unknown values should always be treated as generic failure, and never 
    1119 raise an exception or fail to exit (from #374). 
    1120  
    1121   * '''Proposals:'''  
    1122     * '''boolean:''' Only `#t`/`#f` are as described as above, and all other values are passed (as best as possible) to the OS and therefore implementation-defined 
    1123     * '''extended-true:''' `#f` is generic failure, `#t` generic success, and `""` and `0` are generic success if not otherwise understood by the OS 
    1124   * '''Options:''' boolean, extended-true, unspecified, undecided 
    1125   * '''Default:''' unspecified 
    1126   * '''Preferences:'''  
    1127  
    1128 === #375 Add EMERGENCY-EXIT procedure === 
    1129  
    1130 This procedure provides instant guaranteed process exit without 
    1131 running `dynamic-wind` thunks.  This is a low-level and dangerous 
    1132 procedure. 
    1133  
    1134 Vote `emergency-exit` to add this procedure, or `no` to leave it out. 
    1135 If you want to write in an alternate name, be sure to include 
    1136 `emergency-exit` as a secondary option after it. 
    1137  
    1138   * '''Options:''' emergency-exit, no, undecided 
    1139   * '''Default:''' no 
    1140   * '''Preferences:'''  
    1141  
    1142 === #394 Ditching SCHEME-REPORT-ENVIRONMENT and NULL-ENVIRONMENT === 
    1143  
    1144 Cowan writes: 
    1145  
    1146 "I have reluctantly come to the same conclusion as the R6RS editors: 
    1147 that in a Scheme with libraries, `scheme-report-environment` and 
    1148 `null-environment` don't make much sense.  They are not in IEEE Scheme 
    1149 or R4RS, so there is no formal barrier to removing them. 
    1150  
    1151 "Semantically, `scheme-report-environment` holds all the identifiers in 
    1152 R5RS, excepting any which the implementation doesn't provide, like 
    1153 `make-rectangular` if it does not have complex numbers. 
    1154 `Null-environment`, on the other hand, contains only the syntax 
    1155 keywords with none of the standard procedures: it is not an empty 
    1156 environment.  R6RS preserves these procedures only in the R5RS 
    1157 compatibility library, where they expose only R5RS content. 
    1158  
    1159 "When adapting the definition to R7RS, I changed 
    1160 `scheme-report-environment` to contain all the identifiers in all the 
    1161 standard libraries that the implementation provides, and 
    1162 `null-environment` all the syntax keywords in those libraries.  This 
    1163 was the best I thought I could do, but now I think that it provides 
    1164 very little utility. 
    1165  
    1166 "It's possible to construct any specific environment you want by using 
    1167 the `environment` procedure, which turns a sequence of import-specs 
    1168 into an environment.  In particular, we now have the `(scheme r5rs)` 
    1169 library, which essentially provides what 
    1170 `(scheme-environment-procedure 5)` should provide, and there is no 
    1171 portable use of any argument other than 5." 
    1172  
    1173 Vote `remove` to remove these two procedures entirely, or `move` to 
    1174 move them from (scheme eval) and provide them only as portability 
    1175 options in `(scheme r5rs)`, where only the argument 5 is required to 
    1176 be supported.  Vote `keep` to leave them as-is. 
    1177  
    1178   * '''Options:''' remove, move, keep, undecided 
    1179   * '''Default:''' keep 
    1180   * '''Preferences:'''  
    1181  
    1182 === #413 EVAL accepts DEFINE === 
    1183  
    1184 The proposal is to require `eval` to accept definitions as well as 
    1185 expressions, as long as the specified environment is mutable.  See 
    1186 EvalDefine for which Schemes already handle this. 
    1187  
    1188   * '''Options:''' yes, no, unspecified, undecided 
    1189   * '''Default:''' no 
    1190   * '''Preferences:'''  
    1191  
    1192 === #399 clarify which primitives are allowed to implicitly force === 
    1193  
    1194 The standard allows the following extension to force: 
    1195  
    1196   Some implementations may implement "implicit forcing," where the 
    1197   value of a promise is forced by primitive procedures like `cdr' 
    1198   and `+' 
    1199  
    1200 We should remove this note or tighten the definition. 
    1201  
    1202 A simple definition is any primitive that would require a type-check 
    1203 can perform implicit forcing.  This would include all type predicates 
    1204 themselves except for `promise?`.  Note if #405 passes, then in 
    1205 implementations which support this extension an object could return 
    1206 `#t` for `promise?` in addition to one other type. 
    1207  
    1208   * '''Options:''' remove, type-check, unspecified, undecided 
    1209   * '''Default:''' unspecified 
    1210   * '''Preferences:'''  
    1211  
    1212 === #405 Make promises first-class === 
    1213  
    1214 Currently there is no way to inspect an object to see if it's a 
    1215 promise.  This proposal makes promises first-class by adding a 
    1216 `promise?` predicate.  It also requires that if the argument to 
    1217 `make-promise` is a promise, it is returned without rewrapping it, and 
    1218 that if `force` is given a non-promise argument, it returns it 
    1219 unchanged.  (These things cannot be provided by the user without a 
    1220 `promise?` predicate, and are trivial to provide with it.) 
    1221  
    1222 Vote `disjoint` to add `promise?` and make it a disjoint type, or 
    1223 `yes` to add it as a not-necessarily disjoint predicate. 
    1224  
    1225   * '''Options:''' disjoint, yes, no, undecided 
    1226   * '''Default:''' no 
    1227   * '''Preferences:'''  
    1228  
    1229 === #462 end of line definition === 
    1230  
    1231 The definition of read-line allows implementation defined extensions 
    1232 to the set of end of line sequences. This is arguably too loose, as an 
    1233 implementation could define "a" as and end of line. On the other hand, 
    1234 if we do want to leave this in it may make sense to remove "\r", which 
    1235 is no longer used in any contemporary OS. 
    1236  
    1237 Vote `no-extensions` to forbid implementation defined extensions, 
    1238 `no-return` to remove a single return from the list of required end of 
    1239 lines, and `none` to leave as-is. 
    1240  
    1241   * '''Options:''' no-extensions, no-return, none, undecided 
    1242   * '''Default:''' none 
    1243   * '''Preferences:'''  
    1244  
    1245 === #452 provide digit-value support for non-decimal-digits === 
    1246  
    1247 In ballot 4, in symmetry with the new Unicode definition of 
    1248 `char-numeric?` and as an analog to CL's `digit-char-p`, we provided 
    1249 `digit-value`. 
    1250  
    1251 An informal comment was made questioning this procedure, and 
    1252 suggesting if provided at all it be extended to hex digits. 
    1253  
    1254 Vote `ascii-hex` to support only the ASCII hex digits a-f,A-F (in 
    1255 addition to full Unicode numeric digits), `unicode-hex` to support all 
    1256 Unicode variants of a-f,A-F (need to define formally). 
    1257  
    1258 Vote `ascii-radix` or `unicode-radix` to have both `digit-value` and `char-numeric?` take a radix argument, such that `char-numeric?` returns #t and `digit-value` returns the appropriate value for characters representing non-numeric digits of that radix under ASCII or Unicode character encodings, respectively, and for characters representing numeric digits under Unicode.  Implementations are required to support at least the radix values: 2, 8, 10, and 16, and may support others. 
    1259  
    1260 Vote `remove` to remove `digit-value` entirely, `remove-radix` to remove `digit-value` entirely, but add the radix argument to `char-numeric?` as described above, or `keep` to keep as is. 
    1261  
    1262   * '''Options:''' ascii-hex, unicode-hex, ascii-radix, unicode-radix, remove, remove-radix, keep, undecided 
    1263   * '''Default:''' keep 
    1264   * '''Preferences:'''  
    1265  
    1266 == WG1 - Non-normative == 
    1267  
    1268 === #411 Reference implementation === 
    1269  
    1270 Our charter calls for one or more reference implementations.  As of 
    1271 today, Chibi is very close to being so.  The proposal is to bless it 
    1272 as a sample or model implementation, but not technically a reference 
    1273 implementation -- if it disagrees with the standard, the standard 
    1274 wins. 
    1275  
    1276   * '''Options:''' yes, no, undecided 
    1277   * '''Default:''' no 
    1278   * '''Preferences:'''  
    1279  
    1280 === #463 library naming conventions  === 
    1281  
    1282 We currently use the singular form of data types for library names, 
    1283 e.g. `(scheme char)` and `(scheme file)`.  R6RS prefers the plural, as 
    1284 in `(scheme lists)` and `(scheme records)`. We should decide 
    1285 officially which is preferred. 
    1286  
    1287   * '''Options:''' singular, plural, unspecified, undecided 
    1288   * '''Default:''' unspecified 
    1289   * '''Preferences:'''  
    1290  
    1291  
    1292 == WG1 - Late additions == 
    1293  
    1294 === #465 Add jiffy-modulus to specify when, if ever, current-jiffy wraps === 
    1295  
    1296 If the value of `current-jiffy` is to be both space-efficient (that is, a fixnum) and reasonably precise (say, microsecond timing), it needs to wrap around: 30-bit fixnums on a 32-bit system will wrap every 17 minutes.  That means an application needs to know what the maximum value is before it wraps back to zero.  The `jiffy-modulus` function returns the maximum value of the current jiffy plus 1.  Alternatively, jiffies can be signed and wrap from (- (jiffy-modulus) 1) to (- (jiffy-modulus)), which is easier for the implementation but harder for the user. 
    1297  
    1298   * '''Options:''' unsigned, signed, no, undecided 
    1299   * '''Default:''' no 
    1300   * '''Preferences:'''  
    1301  
    1302 === #466 case folding of character names === 
    1303  
    1304 In ticket #11 we voted to make the reader case-sensitive 
    1305 by default. In ticket #92 we further added the R6RS 
    1306 #!fold-case and #!no-fold-case reader extensions. In 
    1307 both cases the terminology was lax and simply referred 
    1308 to "reader case sensitivity", and all discussion centered 
    1309 around symbols, although in R6RS character names were 
    1310 also affected. 
    1311  
    1312 Case folding will apply to numeric literals, booleans and 
    1313 bytevectors regardless, as they do in both R5RS and R6RS. 
    1314 We need to clarify how character names and the case 
    1315 folding directives themselves are handled. 
    1316  
    1317 The default is `r6rs`, where character names are case 
    1318 sensitive by default and folded by the `#!fold-case` flag: 
    1319  
    1320 ​http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-4.html#node_chap_B 
    1321  
    1322 Alternately character names could be made to ignore 
    1323 the reader directives and always or never fold case. 
    1324 Never folding case breaks R5RS and earlier compatibility 
    1325 without any easy workaround. 
    1326  
    1327 These same settings apply to the `include-ci` syntax. 
    1328  
    1329   * '''Proposals:''' 
    1330     * '''r6rs:''' character names behave like symbols, directives are sensitive 
    1331     * '''r6rs+directives:''' like `r6rs` but directives can also be case-folded 
    1332     * '''always-fold:''' like `r6rs` but character names and directives always fold case 
    1333     * '''never-fold:''' like `r6rs` but character names and directives never fold case 
    1334   * '''Options:''' r6rs, r6rs+directives, always-fold, never-fold, undecided 
    1335   * '''Default:''' r6rs 
    1336   * '''Preferences:'''  
    1337  
    1338 === #467 Allow eqv? and eq? to return different answers on procedures as well as integers and characters === 
    1339  
    1340 This proposal stems from [http://lists.r6rs.org/pipermail/r6rs-discuss/2012-July/006405.html remarks] by Alaric Snell-Pym and Will Clinger on the r6rs public mailing list.  If `eq?` is allowed to return `#f` on two procedures when `eqv?` nevertheless returns `#t`, as is already the case for numbers and characters, then more intelligent implementation-specific procedure comparisons using `eqv?` are possible, while still keeping `eq?` simple enough to inline easily. 
    1341  
    1342 Note that this is orthogonal to the question of #460, how `eqv?` works on procedures.  There should be little or no backward-compatibility hit for this change. 
    1343  
    1344   * '''Proposals:''' 
    1345     * '''same:''' `eq?` and `eqv?` always return the same on procedures, per R5RS and R6RS 
    1346     * '''different:''' `eq?` may return `#f` on procedures even when `eqv?` returns `#t` (but not vice versa) 
    1347   * '''Options:''' same, different, undecided 
    1348   * '''Default:''' same 
    1349   * '''Preferences:''' undecided 
    1350  
    1351 It could be reasonable to allow a scenario where eq? compares 
    1352 procedures by location tags and eqv? does something coarser, like 
    1353 alpha renaming.  I would, however, strongly object to allowing 
    1354 {{{ 
    1355 (let ((x (lambda ...))) 
    1356   (eq? x x)) 
    1357 }}} 
    1358 to evaluate to #f.  I do not see any options on this item that I 
    1359 understand to correspond with this, which is the definition of 
    1360 "further discussion". 
     110  * '''Preferences:''' representational, r5rs, r6rs