Changes between Version 3 and Version 4 of WG1BallotRadul

12/03/12 19:49:44 (4 years ago)



  • WG1BallotRadul

    v3 v4  
     1= Notes about Results = 
    3 = Instructions = 
    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.  
    16 = WG1 Ballot Items To Finalize By July 31 = 
     3See [wiki:WG1BallotExplanation WG1BallotExplanation]. 
    185== WG1 - Core == 
    207=== #460 Semantics of `eqv?` === 
    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. 
    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. 
    31 R2RS had the simplest historical rule which was simply to use `=`. 
    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. 
    38   The `eqv?` procedure returns #t if: 
     22Ultra-brief history: 
    40   (1) obj1 and obj2 are both booleans and are the same according 
    41   to the `boolean=?` procedure. 
    43   (2) obj1 and obj2 are both symbols and are the same symbol 
    44   according to the `symbol=?` procedure. 
    46   (3) obj1 and obj2 are both numbers, have the same exactness, are 
    47   numerically equal (see `=`). 
    49   (4) obj1 and obj2 are both characters and are the same 
    50   character according to the `char=?` procedure. 
    52   (5) obj1 and obj2 are both the empty list. 
    54   (6) obj1 and obj2 are pairs, vectors, bytevectors, records, 
    55   or strings that denote the same location in the store. 
    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 
    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. 
    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: 
     55  (3) obj1 and obj2 are both numbers, have the same exactness, and are 
     56  numerically equal (see `=`). 
     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: 
    7071  equal (see `=`) 
    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. 
    79 where "standard arithmetic procedures" refers arguably to either 
    80 11.7 or  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: 
    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 }}} 
    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. 
    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. 
    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: 
    11090  equal (see `=`) 
    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?` 
    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 
    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 
    124 Keep in mind the semantics of `eqv?` also affect `memv`, `assv` and 
    125 `case`. 
    127103  * '''References:''' 
    128104    * [ eqv? issues summarized] 
    129105    * [ the history of eqv? on numbers] 
    130   * '''Options:''' r5rs, r6rs, r6rs/all, same-bits 
     106    * [ Weaver's objection] 
     107    * [ Lucier on IEEE 754] 
     108  * '''Options:''' r5rs, r6rs, representational 
    131109  * '''Default:''' r5rs 
    132   * '''Preferences:''' same-bits, r5rs 
    134 === #229 eqv? and NaN === 
    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. 
    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. 
    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. 
    154 The default of `unspecified` still holds from the previous invalidated 
    155 ballot. 
    157   * '''Options:''' no-exception, unspecified, undecided 
    158   * '''Default:''' unspecified 
    159   * '''Preferences:''' no-exception 
    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?. 
    166 === #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) === 
    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. 
    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: 
    177 {{{ 
    178 (let ((square (lambda (x) (* x x)))) 
    179   (eqv? square square)) 
    180 }}} 
    182 it is reasonable for a compiler to perform the optimization: 
    184 {{{ 
    185 (eqv? (lambda (x) (* x x)) (lambda (x) (* x x))) 
    186 }}} 
    188 in which case the result would naturally return `#f`. 
    190 Vote `yes` to allow the result to be `#f`. 
    192 The default of `yes` still holds from the previous invalidated ballot. 
    194   * '''Options:''' yes, no, undecided 
    195   * '''Default:''' yes 
    196   * '''Preferences:''' no 
    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.) 
    214 === #393 Defining record equality === 
    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. 
    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. 
    227 Note `equal?` is already required to handle cycles regardless. 
    229   * '''Options:''' recursive, identity, unspecified, undecided 
    230   * '''Default:''' unspecified 
    231   * '''Preferences:''' unspecified 
    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". 
    248 === #306 What does "full Unicode" support mean in Appendix B? === 
    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? 
    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. 
    262   * '''Options:''' at-least-6, at-least-6.1, latest, parameterize, undecided, unspecified 
    263   * '''Default:''' unspecified 
    264   * '''Preferences:'''  
    266 === #458 Remove the formal semantics from the report === 
    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. 
    273 The semantics have been updated to include `dynamic-wind`, however the 
    274 other arguments still hold. 
    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. 
    283 Alternately, we can adapt the operational semantics from R6RS. 
    285   * '''Options:''' remove, keep, operational, undecided 
    286   * '''Default:''' keep 
    287   * '''Preferences:'''  
    289 === #398 Allow repeated keys in `case` === 
    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. 
    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. 
    302   * '''Options:''' r5rs, r6rs, leftmost, unspecified, undecided 
    303   * '''Default:''' r5rs 
    304   * '''Preferences:''' leftmost 
    306 === #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? 
    308 Following exactly in the footsteps of R6RS we voted for a `blob` API 
    309 and then changed the name to `bytevector`. 
    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. 
    316   * '''Options:''' blob, bytevector, byte-vector, u8vector, octet-vector, undecided 
    317   * '''Default:''' bytevector 
    318   * '''Preferences:'''  
    320 == WG1 - Library System == 
    322 === #353 No use before import in libraries === 
    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. 
    330 Therefore, this would be an error (but still permitted as an extension 
    331 in Schemes that can easily provide it): 
    333 {{{ 
    334 (module 
    335   (begin (define x y)) 
    336   (import (library defining y)) 
    337 }}} 
    339 This would necessitate replacing the penultimate paragraph of section 
    340 5.5.1 with: 
    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. 
    353 Vote `yes` to add the restriction, or `no` to leave it out. 
    355   * '''Options:''' yes, no, undecided 
    356   * '''Default:''' no 
    357   * '''Preferences:'''  
    359 === #359 Limit numbers used in library names === 
    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. 
    365 Numbers are mostly used for SRFI-based libraries anyway, which are not 
    366 likely to reach either limit. 
    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. 
    371 Vote `unspecified` to make no explicit requirement on the integers 
    372 allowed in library names. 
    374   * '''Options:''' uint15, int16, uint16, int24, uint24, unspecified, undecided 
    375   * '''Default:''' unspecified 
    376   * '''Preferences:''' uint15, uint16, unspecified 
    378 === #441 Make sure a program/library loads any imported libraries at most once === 
    380 Add the following text to the discussion of library loading: 
    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. 
    387 to make it clear that, for example, 
    389 {{{ 
    390 (import (prefix (foo) 'foo:)) 
    391 (import (only (foo) bar)) 
    392 }}} 
    394 will cause `bar` and `foo:bar` to come from the same instantiation of 
    395 the library '(foo)' 
    397 Vote `yes` to add this requirement. 
    399   * '''Options:''' yes, no, unspecified, undecided 
    400   * '''Default:''' unspecified 
    401   * '''Preferences:''' yes, unspecified 
    403 === #402 Add an export-all form. === 
    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." 
    409   * '''Options:''' yes, no, undecided 
    410   * '''Default:''' no 
    411   * '''Preferences:''' yes 
    413 This is definitely going to be the common case. 
    415 === #448 Add library declaration include-library-declarations === 
    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. 
    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. 
    428   * '''Options:''' include-library-declarations, export-from, no, undecided 
    429   * '''Default:''' no 
    430   * '''Preferences:''' undecided 
    432 === #449 Clarify library loading rules === 
    434 R7RS currently says: 
    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. 
    440 Richard Kelsey thinks this is too liberal, and proposes: 
    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. 
    447 Aaron Hsu, however, thinks this is too restrictive, and proposes 
    448 (backed up by actual R6RS implementations): 
    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. 
    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. 
    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 
    469 == WG1 - Numerics == 
    471 === #366 Add (log z b) for logarithm of z to the base b === 
    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''. 
    479 Vote `yes` to add the optional second argument from R6RS. 
    481   * '''Options:''' yes, no, undecided 
    482   * '''Default:''' no 
    483   * '''Preferences:''' 
    485 === #367 Inexact division by exact zero === 
    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. 
    494 Cowan tested `(/ 2.0 0)` in the usual set of Schemes: 
    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. 
    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. 
    506   * '''Options:''' error, all-error, unspecified, undecided 
    507   * '''Default:''' error 
    508   * '''Preferences:''' error, unspecified 
    510 === #369 Require that - and / allow an arbitrary number of arguments === 
    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. 
    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.) 
    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. 
    524   * '''Options:''' required, optional, forbidden, undecided 
    525   * '''Default:''' optional 
    526   * '''Preferences:''' required 
    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. 
    531 === #370 Log of exact and inexact zero === 
    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. 
    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. 
    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. 
    546 Elk, UMB, Oaklisp raise an exception in both cases. 
    548 Scheme 7 returns the wrong answer in both cases. 
    550 !SigScheme, Shoe, !TinyScheme, Dream, BDC, Owl Lisp don't support `log`. 
    552 Scheme 9 apparently goes into an infinite loop in both cases. 
    554 Vote `r6rs` for the R6RS behavior of returning `-inf.0` and raising an 
    555 error, respectively.  Vote `infinity` to always return `-inf.0`. 
    557   * '''Options:''' r6rs, infinity, unspecified, undecided 
    558   * '''Default:''' unspecified 
    559   * '''Preferences:'''  
    561 === #407 Dividing exact 0 by an inexact number === 
    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. 
    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`. 
    571   * '''Options:''' zero, no-nan, unspecified, undecided 
    572   * '''Default:''' unspecified 
    573   * '''Preferences:''' zero 
    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. 
    582 === #410 Infinity vs. NaN in max and min === 
    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. 
    590 The proposal is to allow R7RS implementations to provide either value. 
    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). 
    597   * '''Options:''' both, infinity, nan, unspecified, undecided 
    598   * '''Default:''' unspecified 
    599   * '''Preferences:''' unspecified 
    601 === #395 Infinite and NaN complex numbers === 
    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? 
    607 Note it is reasonable for an implementation to not support partial nan 
    608 complex numbers. 
    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. 
    614   * '''Options:''' overlap, disjoint, unspecified, undecided 
    615   * '''Default:''' overlap 
    616   * '''Preferences:''' disjoint 
    618 === #364 truncate, floor, ceiling round should return a non-finite argument === 
    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. 
    624 Tests were made for `(round (* 1.0e200 1.0e200))` on a variety of 
    625 implementations. 
    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. 
    632 MIT, Gambit, Scheme48/scsh, SISC, Scheme 9, Scheme 7, signal errors. 
    634 SigScheme, TinyScheme, Dream, UMB don't work for one or another 
    635 reason. 
    637 Oaklisp and Owl Lisp don't do flonums. 
    639 XLisp only has fixnums and flonums, and returns the largest or 
    640 smallest fixnum as the case may be. 
    642 RScheme returns a variety of slightly strange values: (round +inf.0), 
    643 for example, is 0, but (round -inf.0) is -inf.0. 
    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. 
    648   * '''Options:''' input, error, unspecified, undecided 
    649   * '''Default:''' unspecified 
    650   * '''Preferences:''' input 
    652 === #392 Exact positive and non-negative integer predicates === 
    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. 
    662 Vote `yes` to add these two procedures. 
    664   * '''Options:''' yes, no, wg2, undecided 
    665   * '''Default:''' no 
    666   * '''Preferences:'''  
    668 == WG1 - Read/Write == 
    670 === #380 Is support of TAB as a whitespace character required or not? === 
    672 2.2 says: 
    674 Whitespace characters include the space and newline characters. 
    675 (Implementations may provide additional whitespace characters such as 
    676 tab or page break.) 
    678 However, 7.1.1 has: 
    680 <intraline whitespace> -> <space or tab> 
    681 <whitespace> -> <intraline whitespace> | <newline> | <return> 
    683 So 2.2 implies that supporting tabs is allowed but not required, yet 
    684 7.1.1 implies supporting tabs is required. 
    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. 
    690   * '''Options:''' required, optional, undecided 
    691   * '''Default:''' optional 
    692   * '''Preferences:''' required 
    694 === #388 Specify what `display` does with circular lists === 
    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? 
    700   * '''Options:''' labels, loop, unspecified 
    701   * '''Default:''' unspecified 
    702   * '''Preferences:'''  
    704 === #447 #!fold-case and #!no-fold-case have no final delimiter === 
    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. 
    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:'''  
    720 === #442 write procedure is not backwards compatible === 
    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. 
    726 Specifically, even though there are no cycles in 
    728   `(let ((x (list 2))) (write (list x x)))` 
    730 it previously output "((2) (2))" but now outputs "(#0=(2) #0#)". 
    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. 
    737 Arguably, there are three procedures desired: 
    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 
    743 although even for `write-shared` people sometimes want to treat 
    744 containers such as strings separately. 
    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. 
    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 
    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. 
    768 === #219 Bring back readable boolean literals === 
    770 Scheme used to use `#!true` and `#!false` before abbreviating to 
    771 the `#t` and `#f` syntax. 
    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. 
    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. 
    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. 
    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. 
    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. 
    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 
    801 === #443 Recommend sources of character names === 
    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 [ names in 
    806 the Unicode Standard], and the [ 
    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). 
    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). 
    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. 
    824   * '''Options:''' w3c, unicode, unspecified, undecided 
    825   * '''Default:''' unspecified 
    826   * '''Preferences:'''  
    828 == WG1 - Base Library == 
    830 === #140 Removing `quotient`, `remainder`, `modulo` === 
    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. 
    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). 
    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`. 
    848 Arguably the new division operator names are clearer, but the old 
    849 names are not actually misleading. 
    851 Vote `yes` to remove the old names from (scheme base), or `no` to 
    852 leave them in as aliases. 
    854   * '''Options:''' yes, no, undecided 
    855   * '''Default:''' no 
    856   * '''Preferences:''' no 
    858 === #378 Rename GET-FEATURES to just FEATURES === 
    860 This is compatible with Chicken, and "more Scheme-like, less 
    861 Java-like".  Okay, it's bikeshedding. 
    863   * '''Options:''' features, get-features, undecided 
    864   * '''Default:''' get-features 
    865   * '''Preferences:''' features 
    867 === #384 Merge `bytevector-copy` and `bytevector-copy-partial` === 
    869 Under this proposal, the name would be `bytevector-copy` and the 
    870 signature would be 
    872   `(bytevector-copy `''bytevector'' [''start'' [''end'']]`)` 
    874 Vote `yes` for this simplification. 
    876   * '''Options:''' yes, no, undecided 
    877   * '''Default:''' no 
    878   * '''Preferences:'''  
    880 === #385 Merge `write-bytevector` and `write-bytevector-partial` === 
    882 One proposal is `port-last` with a signature of: 
    884   `(write-bytevector ''bytevector'' [''start'' [''end'' [''port'']]])` 
    886 This has the disadvantage of being required to call 
    887 `bytevector-length` when writing to a specific port. 
    889 Alternately we could do `offsets-last`: 
    891   `(write-bytevector ''bytevector'' [''port'' [''start'' [''end'']]])` 
    893 which has the disadvantage of separating the bytevector from its 
    894 offsets. 
    896 Alternately, vote `separate` to keep these as two separate procedures. 
    898   * '''Options:''' port-last, offsets-last, separate, undecided 
    899   * '''Default:''' separate 
    900   * '''Preferences:'''  
    902 === #387 Add start/end arguments to string->vector and vector->string === 
    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. 
    911 Vote `yes` to add these optional arguments. 
    913   * '''Options:''' yes, no, undecided 
    914   * '''Default:''' no 
    915   * '''Preferences:''' yes 
    917 === #391 Add predicates for R7RS signalled conditions === 
    919 R7RS requires an error to be signalled (which means an exception is 
    920 raised as if by `raise`) in the following circumstances: 
    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). 
    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. 
    935 Vote `yes` to add these procedures, or `file-only` to only add the 
    936 `file-error?` predicate. 
    938   * '''Options:''' yes, file-only, no, undecided 
    939   * '''Default:''' no 
    940   * '''Preferences:'''  
    942 === #400 Define record? . === 
    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. 
    949 This is Alexey Radul's suggestion. 
    951   * '''Options:''' yes, no, undecided 
    952   * '''Default:''' no 
    953   * '''Preferences:'''  
    955 === #425 Add read-string, read-string!, write-string procedures to (scheme base) === 
    957 This was requested by Formal Comment #424. 
    959 These procedures would be provided for parallelism with the 
    960 byte-vector I/O operations: 
    962 ||Byte||Character||Bytevector||String|| 
    963 ||read-u8||read-char||read-bytevector(!)||read-string(!)|| 
    964 ||write-u8||write-char||write-bytevector||write-string|| 
    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. 
    970 Vote `yes` to add all three, `immutable` to add only `read-string` and 
    971 `write-string`, or `no` to leave them out. 
    973   * '''Options:''' yes, immutable, no, undecided 
    974   * '''Default:''' no 
    975   * '''Preferences:'''  
    977 === #433 full conversion cycle for containers === 
    979 Marc Feeley proposes it should be possible to convert from any 
    980 container type to another, possibly via an intermediary such as 
    982   `(list->B (A->list a))` 
    984 proposing specifically "list" be the universally available 
    985 intermediary, although "vector" would also be worth considering. 
    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. 
    992 Vote `list` for the proposal to add the following procedures to 
    993 complete the cycle: 
    995   * list->bytevector 
    996   * bytevector->list 
    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: 
    1002   * vector->bytevector 
    1003   * bytevector->vector 
    1005 Vote `list+vector` to add both list and vector conversions. 
    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. 
    1011 The `matrix` proposal requires all 4^3^=64 conversions. 
    1013   * '''Options:''' matrix, list, vector, list+vector, latin-1, no, undecided 
    1014   * '''Default:''' no 
    1015   * '''Preferences:'''  
    1017 === #444 Add vector-append procedure === 
    1019 This is for completeness with `append` and `string-append`.  See #436 
    1020 for the Formal Comment that triggered this ticket. 
    1022   * '''Options:''' yes, no, undecided 
    1023   * '''Default:''' no 
    1024   * '''Preferences:'''  
    1026 === #451 Add bytevector-append procedure === 
    1028 This is for consistency with `append`, `string-append`, and 
    1029 `vector-append` (per ticket #444) procedures. 
    1031   * '''Options:''' yes, no, undecided 
    1032   * '''Default:''' no 
    1033   * '''Preferences:'''  
    1035 === #445 Bidirectional ports and port-open? === 
    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. 
    1041 Vote `replace` to replace `port-open?` with just the two new versions, 
    1042 or `add` to have all three. 
    1044   * '''Options:''' replace, add, no, undecided 
    1045   * '''Default:''' no 
    1046   * '''Preferences:'''  
    1048 === #450 Eliminate default for fill argument in vector-copy === 
    1050 Marc Feeley writes: 
    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. 
    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. 
    1065   * '''Options:''' required, error, remove, default, undecided 
    1066   * '''Default:''' default 
    1067   * '''Preferences:'''  
    1069 === #404 Make handlers take a raise-continuable? argument. === 
    1071 Pass exception handlers a second, Boolean argument that declares 
    1072 whether the exception is continuable. 
    1074   * '''Options:''' yes, no, undecided 
    1075   * '''Default:''' no 
    1076   * '''Preferences:'''  
    1078 === #464 Add optional start and end parameters to utf8->string and string->utf8. === 
    1080 Per ticket 464, add optional start and end arguments to `utf8->string` 
    1081 and `string->utf8`. 
    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. 
    1087   * '''Options:''' both, string->utf8, utf8->string, neither 
    1088   * '''Default:''' neither 
    1089   * '''Preferences:'''  
    1091 == WG1 - Optional Libraries == 
    1093 === #373 (exit #t) should be the same as (exit) === 
    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." 
    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)`. 
    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). 
    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). 
    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:'''  
    1128 === #375 Add EMERGENCY-EXIT procedure === 
    1130 This procedure provides instant guaranteed process exit without 
    1131 running `dynamic-wind` thunks.  This is a low-level and dangerous 
    1132 procedure. 
    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. 
    1138   * '''Options:''' emergency-exit, no, undecided 
    1139   * '''Default:''' no 
    1140   * '''Preferences:'''  
    1142 === #394 Ditching SCHEME-REPORT-ENVIRONMENT and NULL-ENVIRONMENT === 
    1144 Cowan writes: 
    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. 
    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. 
    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. 
    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." 
    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. 
    1178   * '''Options:''' remove, move, keep, undecided 
    1179   * '''Default:''' keep 
    1180   * '''Preferences:'''  
    1182 === #413 EVAL accepts DEFINE === 
    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. 
    1188   * '''Options:''' yes, no, unspecified, undecided 
    1189   * '''Default:''' no 
    1190   * '''Preferences:'''  
    1192 === #399 clarify which primitives are allowed to implicitly force === 
    1194 The standard allows the following extension to force: 
    1196   Some implementations may implement "implicit forcing," where the 
    1197   value of a promise is forced by primitive procedures like `cdr' 
    1198   and `+' 
    1200 We should remove this note or tighten the definition. 
    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. 
    1208   * '''Options:''' remove, type-check, unspecified, undecided 
    1209   * '''Default:''' unspecified 
    1210   * '''Preferences:'''  
    1212 === #405 Make promises first-class === 
    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.) 
    1222 Vote `disjoint` to add `promise?` and make it a disjoint type, or 
    1223 `yes` to add it as a not-necessarily disjoint predicate. 
    1225   * '''Options:''' disjoint, yes, no, undecided 
    1226   * '''Default:''' no 
    1227   * '''Preferences:'''  
    1229 === #462 end of line definition === 
    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. 
    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. 
    1241   * '''Options:''' no-extensions, no-return, none, undecided 
    1242   * '''Default:''' none 
    1243   * '''Preferences:'''  
    1245 === #452 provide digit-value support for non-decimal-digits === 
    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`. 
    1251 An informal comment was made questioning this procedure, and 
    1252 suggesting if provided at all it be extended to hex digits. 
    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). 
    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. 
    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. 
    1262   * '''Options:''' ascii-hex, unicode-hex, ascii-radix, unicode-radix, remove, remove-radix, keep, undecided 
    1263   * '''Default:''' keep 
    1264   * '''Preferences:'''  
    1266 == WG1 - Non-normative == 
    1268 === #411 Reference implementation === 
    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. 
    1276   * '''Options:''' yes, no, undecided 
    1277   * '''Default:''' no 
    1278   * '''Preferences:'''  
    1280 === #463 library naming conventions  === 
    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. 
    1287   * '''Options:''' singular, plural, unspecified, undecided 
    1288   * '''Default:''' unspecified 
    1289   * '''Preferences:'''  
    1292 == WG1 - Late additions == 
    1294 === #465 Add jiffy-modulus to specify when, if ever, current-jiffy wraps === 
    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. 
    1298   * '''Options:''' unsigned, signed, no, undecided 
    1299   * '''Default:''' no 
    1300   * '''Preferences:'''  
    1302 === #466 case folding of character names === 
    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. 
    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. 
    1317 The default is `r6rs`, where character names are case 
    1318 sensitive by default and folded by the `#!fold-case` flag: 
    1320 ​ 
    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. 
    1327 These same settings apply to the `include-ci` syntax. 
    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:'''  
    1338 === #467 Allow eqv? and eq? to return different answers on procedures as well as integers and characters === 
    1340 This proposal stems from [ 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. 
    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. 
    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 
    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