Changes between Version 9 and Version 10 of WG1BallotLucier


Ignore:
Timestamp:
12/02/12 22:51:58 (5 years ago)
Author:
cowan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotLucier

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