Changes between Version 3 and Version 4 of WG1BallotLucier


Ignore:
Timestamp:
07/10/11 03:42:04 (6 years ago)
Author:
alexshinn
Comment:

adding Lucier's third ballot

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotLucier

    v3 v4  
    55    * You can pipe-delimit (|) options you want to give equal weight to. 
    66    * You may write in your own option if you announce it to the list first. 
    7     * You may specify a variant with option/variant, for example `srfi-1/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. 
     7    * 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. 
    88    * You can write a free-form rationale after the "preferences" line, 
    9     * `module` means "yes, but I want it in a separate module", 
    10     * `wg2` means "no, but I think it should go in WG2". 
    11     * `undecided` means I want to discuss this issue further. 
     9    * module means "yes, but I want it in a separate module", 
     10    * wg2 means "no, but I think it should go in WG2". 
     11    * undecided means I want to discuss this issue further. 
    1212    * Abstain on any item by leaving the preferences blank.  
    1313 
    14 = WG1 Ballot Items To Finalize By Jan. 9 = 
    15  
    16 == WG1 - Core == 
     14= WG1 Ballot Items To Finalize by July 1st = 
     15 
     16= Previous Undecided and Re-opened Ballot Items = 
    1717 
    1818=== #32 user-defined types === 
     
    2121as in SRFI-9, SRFI-99 or the R6RS record system? 
    2222 
     23WG1 voted '''srfi-9''' before.  New arguments against filter 
     24constructors were raised, so the ticket was re-opened. 
     25 
     26References: 
     27  * https://groups.google.com/d/topic/scheme-reports-wg1/BX2F10MO6_k/discussion 
     28 
    2329  * '''Proposals:''' 
    2430    * '''cowan:''' RecordsCowan 
     31    * '''gleckler:''' RecordsGleckler, which is just RecordsCowan plus RecordsArcfide 
    2532    * '''hsu:''' RecordsArcfide 
    2633    * '''medernach:''' AggregatesMedernach 
     
    2835    * '''snellpym:''' UniqueTypesSnellPym 
    2936  * '''Options:''' srfi-9, srfi-57, srfi-99, r6rs, cowan, hsu, medernach, rush, snellpym, none, wg2, undecided 
    30   * '''Default:''' none 
    31   * '''Preferences:''' srfi-9,RecordsArcfide 
    32  
    33 === #50 byte-vectors === 
    34  
    35 Several SRFIs, R6RS, and most Scheme implementations support some sort 
    36 of uniform packed integer vectors.  In particular, these are necessary 
    37 for efficient binary I/O, and for memory mapping, so WG2 will 
    38 certainly want them. 
    39  
    40 Do we provide a syntax and basic API for these in WG1? 
    41  
    42   * '''Proposals:''' 
    43     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-3.html#node_chap_2 R6RS byte-vectors] 
    44     * '''cowan:''' BlobAPI 
    45     * '''snellpym:''' BlobsAndSRFI4SnellPym 
    46   * '''Options:''' r6rs, cowan, snellpym, wg2, none, undecided 
    47   * '''Default:''' none 
    48   * '''Preferences:''' cowan 
    49  
    50 I prefer "full cowan", what he's recommending for WG2. 
    51  
    52 === #55 Lazy evaluation === 
    53  
    54 R5RS provides a simple mechanism for easy cases of lazy evaluation. 
    55 It does not support generalized lazy evaluation, because all built-in 
    56 procedures are eager whether they 'need' to be or not.  The relevant 
    57 identifiers are `delay` and `force`; they are not present in IEEE 
    58 Scheme.  SRFI 45 argues that this pair is insufficient for expressing 
    59 common lazy algorithms in a way that preserves tail recursion, and 
    60 adds `lazy` (equivalent to `(delay (force ...))`, but acting 
    61 atomically) and `eager`.  The semantics of `delay` and `force` remain 
    62 downward compatible. 
    63  
    64 Vote `srfi-45` to add just the bindings `lazy` and `eager` in addition 
    65 to `delay` and `force`, not all of the `srfi-45` utilities.  Vote 
    66 `none` to remove `delay` and `force` from the standard. 
    67  
    68   * '''Options:''' r5rs, srfi-45, none, wg2, undecided 
    69   * '''Default:''' r5rs 
    70   * '''Preferences:''' srfi-45 
    71  
    72 === #57 Random Numbers === 
    73  
    74 Random numbers are useful for a wide variety of applications, 
    75 including cryptography, statistics, games, simulations and genetic 
    76 programming.  Do we want to provide an interface to random number 
    77 generation in WG1 Scheme? 
    78  
    79   * '''Proposals:''' 
    80     * '''srfi-27:''' [http://srfi.schemers.org/srfi-27/srfi-27.html SRFI-27] 
    81     * '''cl:''' RandomnessCommonLisp 
    82     * '''cowan:''' RandomCowan 
    83     * '''hsu:''' RandomnessArcfide 
    84   * '''Options:''' srfi-27, cl, cowan, hsu, none, wg2, undecided 
    85   * '''Default:''' none 
    86   * '''Preferences:''' undecided 
    87  
    88 I don't think we should be trying to provide randomness for cryptography applications, it's too hard (meaning, I don't understand how to do it ;-).  I thought originally that SRFI-27 would be good because it has a good base generator in its default implementation and a good interface for getting random integers and reals.  However, RandomnessCommonLisp provides an interface that may be a better starting point for what we want.  I'd like to separate the generation of inexact and integer random numbers, and also to provide (random-source-later-stream random-source [optional-index]) and (random-source-later-substream random-source [optional-index]), which would provide a basis for applications in "statistics, games, simulations, ... genetic programming" and the other simulation-type applications. 
    89  
    90 === #62 Environment Variables === 
    91  
    92 Currently, there is no standard way to communicate with the context 
    93 from which a Scheme program was started.  This has become pretty 
    94 standardized over time: a list of strings ("command-line arguments") 
    95 and a map from strings to strings ("environment variables") on input, 
    96 and a small integer or string on output ("exit value").  Scheme should 
    97 recognize these realities. 
    98  
    99 We have `command-line` and `exit` from ModulesShinn, so the question 
    100 remains if we should add SRFI-98 environment accessors. 
    101  
    102   * '''Options:''' srfi-98, none, wg2, undecided 
    103   * '''Default:''' none 
    104   * '''Preferences:''' srfi-98 
    105  
    106 === #68 "Undefined value" vs. "undefined values" === 
    107  
    108 In R5RS, many procedures and syntax forms return an "undefined value". 
    109 In R6RS, the corresponding convention is to return "undefined values", 
    110 meaning an undefined number (including zero) of undefined values.  How 
    111 shall R7RS go? 
    112  
    113 Vote `r5rs` for a single undefined value, `r6rs` for zero or more 
    114 undefined values, or `zero` for exactly zero values.  Anything other 
    115 than `r5rs` would break R5RS (and IEEE) compatibility. 
    116  
    117   * '''Options:''' r5rs, r6rs, zero, undecided 
    118   * '''Default:''' r5rs 
    119   * '''Preferences:''' R5RS 
    120  
    121 === #49 Undefined value API === 
    122  
    123 Assuming a single "undefined" value (dependent on the result of #68), 
    124 users sometimes want to test for this value.  If we enforce a unique 
    125 undefined value, one approach is to generate this value explicitly to 
    126 test against, such as `(void)` provided by some implementations. 
    127 Alternately we could provide a test such as `undefined?`.  Either 
    128 approach breaks compatibility with existing extensions, and may be 
    129 prohibitively difficult to implement for compilers lacking a separate 
    130 undefined value type.  Some programmers also consider testing for this 
    131 value sign of a broken design. 
    132  
    133 Vote `generate` for a `(void)` procedure, `test` for `undefined?`, and 
    134 `both` for both. 
    135  
    136   * '''Options:''' generate, test, both, none, wg2, undecided 
    137   * '''Default:''' none 
    138   * '''Preferences:''' generate 
    139  
    140 === #51 support for cyclic structures in primitives === 
    141  
    142 list?, length, equal? and other fundamental primitives may diverge 
    143 when given cyclic data.  In the former two cases, avoiding this is 
    144 simple and not inefficient, and the equivalents are already provided 
    145 in SRFI-1.  In the latter case a 
    146 [http://www.r6rs.org/r6rs-editors/2006-February/000969.html proposal] 
    147 was made and rejected on the R6RS list.  In the former case, R6RS 
    148 seems to require `list?` return `#f` and `length` raise an error. 
    149  
    150 Do we want to specify the behavior when these primitives encounter 
    151 cyclic data? 
    152  
    153 Options are `equal?` to specify `equal?` must terminate on cyclic 
    154 input, `r6rs` to specify R6RS behavior for `list?` and `length`, 
    155 `srfi-1` to specify the SRFI-1 semantics (where `length` returns `#f`) 
    156 and `equal?+r6rs` or `equal?+srfi-1` are options for both. 
    157  
    158   * '''Proposals:'''  
    159     * '''equal?:''' `equal?` is required to do proper checks for cyclic structure to not diverge 
    160     * '''r6rs:''' `list?` should return `#f` and `length` raise an error for cyclic lists 
    161     * '''srfi-1:''' `length` is equivalent to `length+` and returns `#f` for a cyclic list 
    162   * '''Options:''' equal?,r6rs,srfi-1,equal?+r6rs,equal?+srfi-1,no,module,wg2,undecided 
    163   * '''Preferences:''' r6rs 
    164  
    165 === #69 Dynamic Parameters === 
    166  
    167 Old-fashioned Lisps used dynamic extent of variables.  Although Scheme 
    168 has switched to lexical scope, the concept of a dynamic environment 
    169 can be useful in special cases. 
    170  
    171 Instead of special variables, SRFI-39 provides first-class "parameter" 
    172 objects with dynamic bindings.  Do we want to provide something 
    173 similar? 
    174  
    175   * '''Proposals:''' 
    176     * '''srfi-39:''' [http://srfi.schemers.org/srfi-39/srfi-39.html SRFI-39] 
    177     * '''cowan:''' ImmutableParametersCowan 
    178     * '''snellpym:''' ParametersSnellPym 
    179   * '''Options:''' cowan, snellpym, srfi-39, none, wg2, undecided 
    180   * '''Default:''' none 
    181   * '''Preferences:''' srfi-39 
    182  
    183 === #70 accessing the system time === 
    184  
    185 Short of a full time and date library, a single procedure 
    186  
    187   (current-seconds) 
    188  
    189 returning the epoch time in seconds, possibly as a real number, would 
    190 be useful and is sufficient to implement a full library (though access 
    191 to the host system's timezone would be desirable in that case). 
    192  
    193 Since some systems may not have access to a clock, we could make this 
    194 an optional procedure.  Alternately, it could be defined as a simple 
    195 counter in such cases, providing an accurate notion of time ordering 
    196 but no sense of duration. Finally, it could return `#f` in the absense 
    197 of a clock. 
    198  
    199   * '''Proposals:''' 
    200     * '''cowan:''' TimeCowan 
    201     * '''required:''' `(current-seconds)` must return seconds since epoch 
    202     * '''optional:''' `(current-seconds)` is an optional procedure 
    203     * '''counter:''' `(current-seconds)` may just be a counter, returning 0, 1, 2, ... 
    204     * '''return-false:''' `(current-seconds)` may return `#f` if unsupported 
    205   * '''Options:''' cowan, required, optional, counter, return-false, none, wg2, undecided 
    206   * '''Default:''' none 
    207   * '''Preferences:''' optional 
    208  
    209 === #109 elapsed time === 
    210  
    211 Should we have functions allowing a program to compute elapsed time, 
    212 as distinct from calendar time? 
    213  
    214 TimeCowan contains a proposal. 
    215  
    216   * '''Options:''' cowan, yes, no, wg2, undecided 
    217   * '''Default:''' no 
    218   * '''Preferences:'''  
    219  
    220 === #78 Should we have case-lambda? === 
    221  
    222 Should we provide case-lambda as in SRFI 16 and R6RS?  It provides 
    223 simple overloading of procedures based on the number of their 
    224 arguments, and does not require that optional arguments appear only 
    225 after mandatory ones. 
    226  
    227   * '''Options:''' yes, no, module, wg2, undecided 
    228   * '''Default:''' no 
    229   * '''Preferences:''' no 
    230  
    231 === #82 missing port? procedure === 
    232  
    233 It's not clear whether R5RS requires a PORT? procedure or not.  It's 
    234 listed in Section 3.3.2 under Disjointness of Types, but not under 
    235 section 6.6.1 under Ports.  R6RS requires it.  Racket, Gauche, MIT 
    236 Scheme, Gambit, Chicken, Guile, SISC support it; Scheme48/scsh, Kawa, 
    237 and Chibi currently do not. 
    238  
    239 Shall we require it? 
    240  
    241   * '''Options:''' yes, no, module, wg2, undecided 
    242   * '''Default:''' no 
    243   * '''Preferences:''' yes 
    244  
    245 === #107 port status detection === 
    246  
    247 Currently there's no way to determine whether a port is open or 
    248 closed, short of trying to read/write to it and catching an error. 
    249 Do we want to add an interface to this? 
    250  
    251   * '''Options:''' port-open?, port-closed?, both, no, wg2, undecided 
    252   * '''Default:''' no 
    253   * '''Preferences:''' port-open? 
    254  
    255 === #87 Allow multiple producers in `call-with-values` === 
    256  
    257 In R5RS and R6RS, `call-with-values` takes two arguments, both 
    258 procedures.  The first is a ''producer'' of multiple values; the 
    259 second is a ''consumer'', to which the multiple values returned by 
    260 ''producer'' are passed as arguments. 
    261  
    262 A possible extension is to allow multiple ''producer'' arguments, 
    263 flattening all the produced values together, analogous to Common 
    264 Lisp's `multiple-value-call`. 
    265  
    266 Do we add this extension? 
    267  
    268   * '''Options:''' yes, no, wg2, undecided 
    269   * '''Default:''' no 
    270   * '''Preferences:''' no 
    271  
    272 === #88 SRFI 87: => in CASE === 
    273  
    274 SRFI-87 extends `case` with a `=>` clauses, analogous to the use of 
    275 `=>` in `cond` clauses, which allows you to pass the item actually 
    276 matched to a procedure. 
    277  
    278 Do we add this extension? 
    279  
    280   * '''Options:''' yes, no, wg2, undecided 
    281   * '''Default:''' no 
    282   * '''Preferences:''' no 
    283  
    284 === #89 SRFI 61: COND => with generator and guard === 
    285  
    286 SRFI-61 extends `=>` clauses in `cond` with an optional ''guard'' 
    287 form, such that after the value is generated and found to be true, 
    288 it's further checked against the guard.  If the guard returns `#f` the 
    289 clause fails and processing proceeds to the next clause, otherwise the 
    290 clause is accepted as normal. 
    291  
    292 Do we add this extension? 
    293  
    294   * '''Options:''' yes, no, wg2, undecided 
    295   * '''Default:''' no 
    296   * '''Preferences:''' no 
    297  
    298 === #90 Multiple values in COND => clauses === 
    299  
    300 Currently, `=>` clauses in `cond` accept a single value from the 
    301 ''generator'' (right-hand side) and pass it to the ''receiver'' 
    302 (left-hand side).  Shall we allow the generator to return multiple 
    303 values and pass them to the receiver?  If both this ticket and #89 
    304 pass, multiple values would also be allowed for generator/guard `cond` 
    305 clauses. 
    306  
    307   * '''Options:''' yes, no, wg2, undecided 
    308   * '''Default:''' no 
    309   * '''Preferences:''' no 
    310  
    311 Aren't "left-hand side" and "right-hand side" reversed in the description? 
    312  
    313 === #91 INCLUDE at the REPL === 
    314  
    315 Should we allow `(include "''filename''")` at the REPL?  This is 
    316 distinct from `import` in that it just loads code without altering the 
    317 module structure. 
    318  
    319   * '''Options:''' yes, no, wg2, undecided 
    320   * '''Default:''' no 
    321   * '''Preferences:''' no 
    322  
    323 === #92 Case-folding flags === 
    324  
    325 The default reader in R7RS will default to case-sensitive, but users 
    326 may wish to override this in some situations.  R6RS allows at the 
    327 top-level #!case-fold and #!no-case-fold read syntax to control the 
    328 case-sensitivity of the current file.  Many existing R5RS 
    329 implementations, on the other hand, use #ci and #cs, with the 
    330 difference that they refer to the next datum only. 
    331  
    332 Note PortsCowan provides a separate means of controlling 
    333 case-sensitivity per-port. 
    334  
    335 Vote `per-datum` for the next-datum-only #ci/#cs syntax. 
    336  
    337   * '''Options:''' r6rs, per-datum, none, wg2, undecided 
    338   * '''Default:''' none 
    339   * '''Preferences:''' r6rs,none 
    340  
    341 === #116 Source File Character Encoding === 
    342  
    343 The standard currently says nothing about the character encoding 
    344 system of source files.  Do we require this to be a fixed encoding 
    345 such as UTF-8, use an out-of-band specification like the Emacs (and 
    346 Python) `-*- coding: foo -*-` convention, or just leave it 
    347 unspecified? 
    348  
    349   * '''Options:''' utf-8, emacs, unspecified, undecided 
    350   * '''Default:''' none 
    351   * '''Preferences:''' unspecified 
    352  
    353 === #93 Removing string mutability === 
    354  
    355 R6RS relegated `string-set!` to a module, and many modern languages 
    356 tend towards making strings immutable.  Removing entirely, however, 
    357 breaks IEEE Scheme compatibility and should only be considered if you 
    358 believe mutable strings are fundamentally broken. 
    359  
    360 Do we remove `string-set!`?  Vote `yes` to remove, `module` to 
    361 relegate to a module as in R6RS, or `no` to keep as is. 
    362  
    363   * '''Options:''' yes, no, module, undecided 
    364   * '''Default:''' no 
    365   * '''Preferences:''' no 
    366  
    367 === #83 Auxiliary Keywords === 
    368  
    369 In R6RS auxiliary keywords (such as `else` in `cond` and `case` forms) 
    370 are explicitly exported from the `(rnrs base (6))` library.  Do we 
    371 want to bind and export these from the core library? 
    372  
    373 If `else` is bound in the default module, then it must be imported at 
    374 the call site whenever using it in `cond` or it won't match 
    375 hygienically. 
    376  
    377 If `else` is '''not''' bound in the default module, then it must not 
    378 be bound or imported at the call site whenever using it in `cond` or 
    379 it won't match hygienically. 
    380  
    381 Another option is to specify for `cond` and `case` that they match the 
    382 `else` identifier literally, ignoring any hygiene.  This breaks 
    383 compatibility with R5RS and R6RS. 
    384  
    385   * '''Options:''' bound, unbound, unhygienic, undecided 
    386   * '''Preferences:''' undecided 
    387  
    388 === #101 exactness and `eqv?`/`equal?` === 
    389  
    390 In R5RS `eqv?`/`equal?` are in some sense the broadest tests for 
    391 equality, comparing structural equality, but also tests for the same 
    392 exactness, so that 
    393  
    394    {{{(equal? 0 0.0) => #f}}} 
    395  
    396 whereas 
    397  
    398    {{{(= 0 0.0) => #t}}} 
    399  
    400 Some users consider this confusing, others sometimes want an `equal?` 
    401 that behaves like `=` for numbers. 
    402  
    403 Do we want to change `equal?` and `eqv?` in this way, or add a 
    404 separate exactness-agnostic procedure?  Vote `yes` to change, 
    405 `equal=?` or `inexact-equal?` for separate procedures of those names 
    406 (plus the analogous `eqv=?` or `inexact-eqv?`), or `no` to leave as 
    407 is.  Alternately, write in a separate name. 
    408  
    409   * '''Options:''' yes, equal=?, inexact-equal?, no, wg2, undecided 
    410   * '''Default:''' no 
    411   * '''Preferences:''' no 
    412  
    413 Please don't change it.  Numerical equality is something different from eqv? and equal? equality.  Right now we also have (define x (/ 0. 0.)) (eqv? x x) => #t (at least in many Schemes), yet (= x x) => #f.  The needs of numerical = are different from the needs of equal?/eqv?/eq?, and each should be allowed to evolve independently of the other. 
    414  
    415 === #102 module syntax name === 
    416  
    417 A bikeshed color issue, we need to choose the 
    418 actual names for the module syntax for the winner 
    419 of #2. 
    420  
    421 `import`, `export` and `include` are fairly universal 
    422 and no alternate is suggested unless someone wants 
    423 to write in a proposal. 
    424  
    425 The enclosing syntax can be called either 
    426 `library` as in R6RS, `module` or some other proposal. 
    427  
    428   * '''Options:''' library, module, undecided 
    429   * '''Default:''' library 
    430   * '''Preferences:'''  
    431  
    432 === #103 module body syntax name === 
    433  
    434 Similar to #102, we need to choose a name 
    435 for the form to include Scheme code directly 
    436 in a module form.  This can be `body` as in 
    437 the proposal, `begin` or some other name. 
    438  
    439   * '''Options:''' body, begin, scheme, code, undecided 
    440   * '''Default:''' body 
    441   * '''Preferences:'''  
    442  
    443 === #105 case-insensitive module includes === 
    444  
    445 The `include` module form includes files literally 
    446 with the default case-sensitivity.  An `include-ci` 
    447 form could include files case-insensitively 
    448 without resorting to the reader hacks proposed in 
    449 #92, allowing existing R5RS libraries to be used 
    450 without modification. 
    451  
    452   * '''Options:''' yes, no, wg2, undecided 
    453   * '''Default:''' no 
    454   * '''Preferences:''' yes 
    455  
    456 === #106 conditional code selection === 
    457  
    458 Users invariably want some way to conditionally select code depending 
    459 on the implementation and/or feature set available. CondExpandCowan 
    460 allows conditional expansion in the style of SRFI-0 within the module language. 
    461 [http://srfi.schemers.org/srfi-0/srfi-0.html SRFI-0] provides 
    462 `cond-expand`, [http://srfi.schemers.org/srfi-103/srfi-103.html SRFI-103] 
    463 provides a library naming extension, and numerous other personal hacks exist. 
    464  
    465 Do we want to include something along these lines in WG1 Scheme? 
    466  
    467   * '''Proposals:''' 
    468     * '''cowan:''' CondExpandCowan 
    469     * '''srfi-0:''' `cond-expand` only defined as a top-level module form 
    470     * '''srfi-103:''' the search path extension used by R6RS implementations 
    471   * '''Options:''' cowan, srfi-0, srfi-103, none, wg2, undecided 
    472   * '''Default:''' none 
    473   * '''Preferences:'''  
    474  
    475 === #108 immutable data interface === 
    476  
    477 R5RS specifies literal data in source code as immutable, but otherwise 
    478 provides no way to generate or introspect immutable data. 
    479  
    480 One proposal is given in ImmutableData, providing `mutable?`, 
    481 `make-immutable` and `immutable->mutable`. 
    482  
    483 Racket, for which all pairs are immutable in the default language, 
    484 needs some way to generate shared and cyclic data structures at 
    485 runtime, and provides the `shared` syntax for this.  It also has an 
    486 `immutable?` utility as the complement to `mutable?` above. 
    487  
    488   * '''Proposals:''' 
    489     * '''medernach:''' ImmutableData 
    490     * '''racket:''' `shared`, `immutable?` ([http://docs.racket-lang.org/reference/shared.html]) 
    491   * '''Options:''' medernach, racket, no, undecided 
    492   * '''Default:''' no 
    493   * '''Preferences:'''  
    494  
    495 === #111 require `equal?` to return `#t` if `eqv?` does === 
    496  
    497 Currently `equal?` is strictly broader than `eqv?` except in the 
    498 pathological case of comparing the same circular list with itself, for 
    499 which `eqv?` returns true and `equal?` may loop infinitely.  We could 
    500 explicitly require `equal?` to check and return `#t` in this case, 
    501 which most implementations do as a performance hack anyway. 
    502  
    503   * '''Options:''' yes, no, undecided 
    504   * '''Default:''' no 
    505   * '''Preferences:''' yes 
    506  
    507 == WG1 - Exceptions == 
    508  
    509 === #18 exception system === 
    510  
    511 R6RS provided a detailed exception system with support for raising and 
    512 catching exceptions, using a hierarchy of exception types. 
    513  
    514 Do we use this, or parts of it, or a new exception system?  The `r6rs` 
    515 option is just for the core exception handling. 
    516  
    517   * '''Proposals:''' 
    518     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-8.html#node_sec_7.1 R6RS Exceptions] - `with-exception-handler`, `guard`, `raise`, `raise-continuable` 
    519     * '''cowan:''' ExceptionHandlingCowan 
    520   * '''Options:''' cowan, r6rs, wg2, none, undecided 
    521   * '''Default:''' none 
    522   * '''Preferences:'''  
    523  
    524 === #19 when to throw an error === 
    525  
    526 R5RS defines many things as "is an error" without any specification of 
    527 what happens in that situation.  R6RS goes to the opposite extreme and 
    528 specifies as much as possible what exceptions are raised when. 
    529  
    530 Taking into account the system provided by ticket #18, we need to come 
    531 up with guidelines for when exceptions should be raised, and clarify 
    532 which R5RS "error" situations should raise an exception or be left 
    533 unspecified. 
    534  
    535 R5RS specifies only 3 situations where an error is required to be 
    536 signalled, leaving most situations unspecified as described in 
    537 ErrorSituations. 
    538  
    539   * '''Options:''' r5rs, r6rs, undecided 
    540   * '''Default:''' r5rs 
    541   * '''Preferences:'''  
    542  
    543 == WG1 - I/O == 
     37  * '''Default:''' srfi-9 
     38  * '''Preferences:''' srfi-9 
    54439 
    54540=== #28 binary I/O ports === 
     
    54944be mixed on the different port types? 
    55045 
    551 PortsCowan provides binary port operations along with other 
    552 extensions. 
     46BinaryPortsCowan provides binary port operations, being a mild revision of the relevant parts of PortsCowan. 
    55347 
    55448R6RS provides an entirely new I/O system, as well as a separate 
     
    56357aspects will be merged as needed. 
    56458 
     59WG1 voted weakly in favor of PortsCowan before. 
     60 
    56561  * '''Proposals:'''  
    56662    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
    56763    * '''r6rs-simple:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.3 R6RS Simple I/O] 
    56864    * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
    569     * '''cowan:''' PortsCowan (subset relevant to binary I/O) 
     65    * '''cowan:''' BinaryPortsCowan 
    57066  * '''Options:''' r6rs, r6rs-simple, srfi-91, cowan, none, undecided 
    57167  * '''Default:''' none 
    57268  * '''Preferences:''' srfi-91,r6rs-simple,undecided 
    57369 
    574 === #29 port encodings === 
    575  
    576 Do we support encoding and decoding text from ports with different 
    577 character encoding systems?  Different end-of-line conventions? 
    578 Different normalizations?  How are encoding errors handled? 
    579  
    580   * '''Proposals:'''  
    581     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
    582     * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
    583     * '''cowan:''' PortsCowan (subset relevant to port encodings) 
    584   * '''Options:''' r6rs, srfi-91, cowan, none, undecided 
    585   * '''Default:''' none 
    586   * '''Preferences:''' srfi-91,undecided 
    587  
    588 === #31 custom ports === 
    589  
    590 Do we provide a mechanism for custom ports, on which for instance 
    591 string ports could be created? 
    592  
    593 R6RS as well as a number of Scheme implementations provide custom 
    594 ports with various APIs. 
    595  
    596   * '''Proposals:'''  
    597     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
    598   * '''Options:''' r6rs, none 
    599   * '''Default:''' none 
    600   * '''Preferences:'''  
    601  
    602 == WG1 - Libraries == 
    603  
    604 === #36 hash-tables === 
    605  
    606 R6RS and SRFI-69 both provide hash-table interfaces.  Do we provide 
    607 either of these, or try to provide some primitives on which efficient 
    608 hash-tables can be implemented? 
    609  
    610   * '''Options:''' r6rs, srfi-69, no, wg2, undecided 
    611   * '''Default:''' no 
    612   * '''Preferences:''' srfi-69,wg2 
    613  
    614 === #113 directory contents === 
    615  
    616 We've decided to add file-exists? and delete-file, 
    617 essential for a large class of scripts, but still 
    618 have no way to get a list of files in a directory. 
    619 Do we want to provide an interface to this? 
    620  
    621   * '''Proposals:''' 
    622     *  '''cowan:''' DirectoryPortsCowan 
    623     *  '''directory-files:''' return a list of all files in the dir 
    624     *  '''directory-streams:''' [http://www.scsh.net/docu/html/man-Z-H-4.html#node_sec_3.3 SCSH directory stream interface] 
    625   * '''Options:''' directory-files, directory-streams, no, wg2, undecided 
    626   * '''Default:''' no 
    627   * '''Preferences:'''  
    628  
    629 == WG1 - Macros == 
    630  
    631 === #48 let-syntax === 
    632  
    633 `let-syntax` and `letrec-syntax` has known ambiguities in their 
    634 behavior. We have the option of altering the semantics to correct this 
    635 behavior, defining which behavior we intend, or removing `let-syntax` 
    636 entirely.  We could also leave this ambiguity unspecified. 
    637  
    638 The question of whether or not to introduce a new lexical scope 
    639 (i.e. whether internal `define`s are visible outside the `let-syntax`) 
    640 is straightforward. 
    641  
    642 If we don't introduce a new lexical scope, the question arises whether 
    643 or not internal `define-syntax` forms are allowed and whether they 
    644 apply to the body of the `let-syntax`, forms following the 
    645 `let-syntax`, or both. 
    646  
    647 If internal `define-syntax` applies to the body, we may also wish to 
    648 specify what happens when said `define-syntax` redefines an identifier 
    649 bound by the enclosing `let-syntax`.  This varies by implementation 
    650 and may be difficult for macro expanders to change, so is left 
    651 unspecified in the proposals below. 
    652  
    653   * '''Proposals:''' 
    654     * '''hsu:''' LetSyntaxArcfide 
    655     * '''remove:''' remove both of these forms from the standard 
    656     * '''lexical:''' introduces a new lexical contour 
    657     * '''define:''' allows splicing `define`/`begin` 
    658     * '''syntax:''' allows `define-syntax` 
    659     * '''syntax-body:''' allows `define-syntax` only applying to the body 
    660     * '''syntax-follows:'''  allows `define-syntax` only applying to following forms 
    661   * '''Options:''' hsu, remove, lexical, define, syntax, syntax-body, syntax-follows, unspecified, undecided 
    662   * '''Default:''' unspecified 
    663   * '''Preferences:'''  
    664  
    665 === #97 syntax-rules special literals === 
    666  
    667 `...` and with the result of #6 also `_` have special meaning in 
    668 syntax-rules patterns, so they are not treated as pattern variables by 
    669 default. 
    670  
    671 However their behavior when used in the literals list of 
    672 syntax-rules is ambiguous, and simply breaks in most implementations. 
    673  
    674 Rather than breaking, it makes sense to go ahead and treat 
    675 them as normal literals, overriding their special meanings. 
    676  
    677 In particular, there are many existing R5RS macros which 
    678 make use of `_` in the literals and are thus broken outright 
    679 by #6. Allowing them as literals fixes these macros. 
    680  
    681   * '''Options:''' literal, error, unspecified, undecided 
    682   * '''Default:''' unspecified 
    683   * '''Preferences:'''  
    684  
    685 == WG1 - Modules == 
     70=== #83 Auxiliary Keywords === 
     71 
     72In R6RS auxiliary keywords (such as `else` in `cond` and `case` forms) 
     73are explicitly exported from the `(rnrs base (6))` library.  Do we 
     74want to bind and export these from the core library? 
     75 
     76If `else` is bound in the default module, then it must be imported at 
     77the call site whenever using it in `cond` or it won't match 
     78hygienically. 
     79 
     80If `else` is '''not''' bound in the default module, then it must not 
     81be bound or imported at the call site whenever using it in `cond` or 
     82it won't match hygienically. 
     83 
     84Another option is to specify for `cond` and `case` that they match the 
     85`else` identifier literally, ignoring any hygiene.  This breaks 
     86compatibility with R5RS and R6RS. 
     87 
     88WG1 voted '''unbound''' previously.  New issues were brought up on the 
     89list so the ticket was re-opened. 
     90 
     91References: 
     92  * [wiki:Keywords] 
     93  * http://lists.scheme-reports.org/pipermail/scheme-reports/2011-April/thread.html 
     94 
     95  * '''Options:''' bound, unbound, unhygienic, undecided 
     96  * '''Default:''' unbound 
     97  * '''Preferences:''' undecided 
    68698 
    68799=== #3 module naming convention === 
     
    690102libraries of the new module system. 
    691103 
    692 In R5RS everything is effectively in a single module.  R6RS provides a 
    693 much more fine-grained breakdown of modules which could be 
    694 retro-fitted to the bindings we include in our standard. 
    695  
    696 John Cowan has proposed a number of module factorings in items #71, 
    697 #72, #73, #74, #75, #76, #77, as well as an I/O module breakdown in 
    698 PortsCowan. 
    699  
    700 Since the naming and breakdown must be internally consistent I'm 
    701 grouping these into a single ballot item.  Members desiring to put 
    702 forth a new proposal should specify where all bindings belong, or 
    703 specify a subset of the bindings and default the rest to some other 
    704 proposal. 
    705  
    706 Note some ballots specify explicitly whether or not the bindings in 
    707 question are intended to be in a module or the core language.  In 
    708 these cases we still need to decide to which module they belong. 
    709 Where specific votes contradict general factoring proposals, the 
    710 specific vote wins. 
     104The existing break down is based on John Cowan's earlier proposal of 
     105factorings in items #71, #72, #73, #74, #75, #76, #77, as well as an 
     106I/O module breakdown in PortsCowan.  There have been various tickets 
     107proposing changing this, so we are re-opening the ticket. 
    711108 
    712109  * '''Proposals:''' 
     110    * '''draft-1:''' the first draft 
    713111    * '''r5rs:''' one single module 
    714     * '''r6rs:''' 
    715     * '''cowan:''' #71, #72, #73, #74, #75, #76, #77 
    716   * '''Options:''' r5rs, r6rs, cowan, undecided 
     112    * '''r6rs:''' no proposal yet 
     113    * '''cowan:''' ModuleFactoringCowan 
     114    * '''gleckler:''' ModuleFactoringGleckler 
     115    * '''shinn:''' ModuleFactoringShinn 
     116    * '''medernach:''' ModuleFactoringMedernach 
     117  * '''Options:''' draft-1, r5rs, r6rs, cowan, shinn, medernach, undecided 
     118  * '''Default:''' draft-1 
     119  * '''Preferences:''' ModuleFactoringGleckler 
     120 
     121= New Ballot Items = 
     122 
     123== WG1 - Core == 
     124 
     125=== #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? === 
     126 
     127Now that we have blobs, we have to decide what to call them.  R6RS 
     128uses bytevector, SRFI-4 and SRFI-68 uses u8vector, while the original 
     129WG1 proposal used blob (which is therefore the default). 
     130 
     131  * '''Options:''' blob, bytevector, byte-vector, u8vector, octet-vector, undecided 
     132  * '''Default:''' blob 
     133  * '''Preferences:''' bytevector,u8vector 
     134 
     135=== #118 Simple literals must be explicitly delimited. === 
     136 
     137In R5RS syntax such as `#t#f` is left unspecified - some readers may 
     138parse this as the true literal followed by false.  R6RS requires 
     139identifiers, characters, booleans, number objects, and `.` to be 
     140terminated with a "delimiter" or by the end of input. 
     141 
     142References: 
     143  * http://scheme-punks.org/wiki/index.php?title=ERR5RS:Lexical_Syntax 
     144  * http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002649.html 
     145 
     146  * '''Options:''' delimited, unspecified, undecided 
     147  * '''Default:''' unspecified 
     148  * '''Preferences:''' delimited 
     149 
     150=== #119 Whether to treat # as a delimiter. === 
     151 
     152In R5RS `foo#f` is a valid identifier, whereas R6RS requires `#` to 
     153act as a delimiter, so that this would parse as the identifier `foo` 
     154followed by the false literal. 
     155 
     156  * '''Options:'''  delimiter, no, undecided 
     157  * '''Default:''' no 
     158  * '''Preferences:''' no 
     159 
     160=== #123 Extend unquote and unquote-splicing to multiple arguments === 
     161 
     162This is a change also made by R6RS (and CL). 
     163 
     164References: 
     165  * http://lists.scheme-reports.org/pipermail/scheme-reports/2011-April/000448.html 
     166  * http://www.rhinocerus.net/forum/lang-scheme/98742-quasiquote-syntax-rules-macro.html 
     167  * http://www.mail-archive.com/guile-user@gnu.org/msg03899.html 
     168 
     169  * '''Options:''' multiple, single, undecided 
     170  * '''Default:''' single 
     171  * '''Preferences:''' r6rs 
     172 
     173=== #124 Nested quasiquote semantics === 
     174 
     175References: 
     176  * http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.17 
     177  * http://lists.nongnu.org/archive/html/chicken-hackers/2010-12/msg00008.html 
     178 
     179  * '''Proposals:''' 
     180    * '''r5rs:''' unspecified 
     181    * '''r6rs:''' strict and multiple (implies multiple for #123) 
     182    * '''chicken:''' strict at level 0 (option 2 in second reference) 
     183    * '''strict:''' strict at all levels (R6RS with single for #123) 
     184  * '''Options:''' r5rs, r6rs, chicken, strict, undecided 
    717185  * '''Default:''' r5rs 
    718   * '''Preferences:'''  
     186  * '''Preferences:''' r6rs 
     187 
     188=== #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) === 
     189 
     190This is a change also made by R6RS, specifically: 
     191 
     192> A quasiquote expression may return either fresh, mutable objects or literal structure 
     193> for any structure that is constructed at run time during the evaluation of the expression. 
     194> Portions that do not need to be rebuilt are always literal 
     195 
     196  * '''Options:''' r6rs, r5rs, undecided 
     197  * '''Default:''' r5rs 
     198  * '''Preferences:''' r6rs 
     199 
     200=== #126 Partly specify the mutability of the values of quasiquote structures === 
     201 
     202This is a change also made by R6RS. 
     203 
     204  * '''Options:''' r6rs, r5rs, undecided 
     205  * '''Default:''' r5rs 
     206  * '''Preferences:'''  
     207 
     208=== #127 Specify the dynamic environment of the ''before'' and ''after'' procedures of dynamic-wind === 
     209 
     210R5RS is slightly ambiguous, saying 
     211 
     212> BEFORE is called whenever execution enters the dynamic extent of the 
     213> call to THUNK and AFTER is called whenever it exits that dynamic 
     214> extent. 
     215 
     216without saying clearly whether ''before'' and ''after'' themselves are 
     217called before or after the dynamic extent is entered or exited. 
     218 
     219  * '''Proposals:''' 
     220    * '''outside:''' called outside the dynamic extent (R6RS) 
     221    * '''inside:''' called inside the dynamic extent 
     222    * '''unspecified:''' R5RS 
     223  * '''Options:''' outside, inside, unspecified, undecided 
     224  * '''Default:''' unspecified 
     225  * '''Preferences:''' outside 
     226 
     227=== #135 let-values and let*-values === 
     228 
     229These R6RS procedures were part of #77 (modularization of multiple 
     230values), but were never explicitly voted up or down by WG1, so I'm 
     231opening a new ticket for them. 
     232 
     233  * '''Options:''' yes, no, module, wg2, undecided 
     234  * '''Default:''' no 
     235  * '''Preferences:''' yes,module 
     236 
     237=== #137 Current-seconds semantics still open === 
     238 
     239In issue #70, WG1 voted to make `current-seconds` an optional 
     240procedure, but there is no guidance about what it returns. 
     241 
     242If we choose to specify this further, the big question is whether or 
     243not to include leap seconds - i.e. do we specify it as TAI or POSIX 
     244time (the choice of the epoch itself is less controversial and 
     245defaults to the POSIX epoch).  TAI time has the advantage that it 
     246measures real, unambiguous time, and two calls to current-seconds more 
     247than a second apart are guaranteed to actually differ.  POSIX time has 
     248the advantage of bug-for-bug compatibility with POSIX systems - the 
     249times are ambiguous, but they already have to deal with that. 
     250 
     251The other issue is whether to return an integral number of seconds and 
     252lose the ability to specify subsecond real times, or return an inexact 
     253real (flonum) number of seconds and have to deal with variable 
     254precision depending on the date. 
     255 
     256TimeCowan is equivalent to the `posix-integer` option, and in addition 
     257changes the name to `current-posix-second`. 
     258 
     259  * '''Proposals:''' 
     260    * '''cowan:''' TimeCowan 
     261    * '''posix-integer:''' POSIX time as an exact integer value 
     262    * '''posix-flonum:''' POSIX time as an inexact real value 
     263    * '''tai-integer:''' TAI time as an exact integer value 
     264    * '''tai-flonum:''' TAI time as an inexact real value 
     265  * '''Options:''' cowan, unspecified, undecided, none 
     266  * '''Default:''' unspecified 
     267  * '''Preferences:''' tai-flonum,posix-flonum 
     268 
     269=== #147 Allow literal file spec lists in include and include-ci === 
     270 
     271This could allow implementation-specific extensions to support files 
     272don't have character-string names.  On the other hand, such names 
     273probably shouldn't be used as source files, and there are other ways 
     274to support this. 
     275 
     276  * '''Options:''' yes, no, undecided 
     277  * '''Default:''' no 
     278  * '''Preferences:'''  
     279 
     280=== #148 Allow include-ci at top level === 
     281 
     282Currently `include-ci` is allowed as a module declaration but not at top level, 
     283as `include` is. 
     284 
     285  * '''Options:''' yes, no, undecided 
     286  * '''Default:''' no 
     287  * '''Preferences:''' yes 
     288 
     289=== #149 blob ports === 
     290 
     291We've voted to add string ports, which are character ports backed by 
     292Scheme strings.  Since we have blobs another potential extension is 
     293blob ports, which binary ports backed by blobs.  These are described 
     294in PortsCowan, but it's unclear if they were specifically voted for or 
     295against in the previous ballot. 
     296 
     297  * '''Options:''' cowan, none, undecided 
     298  * '''Default:''' none 
     299  * '''Preferences:''' cowan 
     300 
     301=== #150 cond-expand at top level === 
     302 
     303Currently `cond-expand` is only valid as a module declaration.  Should 
     304we allow it at top level in a program? 
     305 
     306  * '''Options:''' yes, no, undecided 
     307  * '''Default:''' no 
     308  * '''Preferences:''' yes 
     309 
     310=== #153 Renaming blob procedures === 
     311 
     312The blob procedures don't follow the same system as the rest.  I 
     313propose these changes: 
     314 
     315{{{ 
     316copy-blob => blob-copy 
     317copy-blob! => blob-copy! 
     318partial-blob => blob-copy-partial 
     319copy-partial-blob! -> blob-copy-partial! 
     320}}} 
     321 
     322Note this is modulo the choice of "blob" or "bytevector" 
     323or whichever. 
     324 
     325  * '''Options:''' new, original, remove, undecided 
     326  * '''Default:''' original 
     327  * '''Preferences:''' new 
     328 
     329=== #154 Physical newline in a string equivalent to \n (that is, U+000A) === 
     330 
     331R5RS leaves this situation undefined, but R6RS, CL, and most languages 
     332that allow it (C does not) treat physical newline and escaped newline 
     333as equivalent, even if the local representation of line endings is 
     334\r\n or U+0085 or what not.  Another possibility is to treat string literals 
     335broken across lines as errors. 
     336 
     337  * '''Options:''' unix, local, error, unspecified, undecided 
     338  * '''Default:''' unspecified 
     339  * '''Preferences:'''  
     340 
     341=== #155 Make recursively defined code an explicit error === 
     342 
     343Allowing examples like these will make code-walkers (including 
     344compilers and interpreters) excessively complicated: 
     345 
     346#1=(begin (display #\x) . #1#) 
     347 
     348(lambda #2=(a b c #2#) ...) 
     349 
     350(+ . #3=(1 2 3 . #3#)) 
     351 
     352  * '''Options:''' error, unspecified, undecided 
     353  * '''Default:''' unspecified 
     354  * '''Preferences:''' error 
     355 
     356=== #156 Replace "an error is signalled" with "an implementation-dependent object is raised as if by `raise`" === 
     357 
     358The following situations are described in draft 1 (and R5RS) with "an 
     359error is signalled": 
     360 
     361 1. The ''file-spec'' given to `call-with-input-file`, 
     362 `call-with-output-file`, `open-input-file`, or `open-output-file` 
     363 represents a file that cannot be opened. 
     364 
     365 2. An end of file is read from a port by `read` after the beginning 
     366 of an object's external representation, but the external 
     367 representation is incomplete and therefore not parsable. 
     368 
     369I propose that in both cases the implementation be required to raise 
     370an exception as if by applying `raise` (that is, non-continuably) to 
     371an implementation-defined object, which means it can be caught by the 
     372R7RS exception system.  Note that there is no requirement to create a 
     373fresh object. 
     374 
     375  * '''Options:''' signal, unspecified, undecided 
     376  * '''Default:''' unspecified 
     377  * '''Preferences:''' undecided 
     378 
     379=== #162 Remove DELAY and FORCE altogether === 
     380 
     381They are present in R4RS and R5RS, but not IEEE Scheme (which is our 
     382baseline).  There are problems with a straightforward implementation 
     383that SRFI 45 fixes, but we voted down SRFI 45.  Given that, we should 
     384consider removing them from the standard altogether.  (Of course this 
     385does not mean compliant implementations can't provide them, it just 
     386means they won't be in a standard module.) 
     387 
     388Since the inconsistency was raised and people are going so far as 
     389to remove these, we can entertain votes for SRFI-45's `lazy` again. 
     390 
     391  * '''Options:''' remove, keep, lazy, undecided 
     392  * '''Default:''' keep 
     393  * '''Preferences:''' keep,lazy 
     394 
     395=== #164 Meaning of char-numeric? === 
     396 
     397The current draft, like R6RS, defines `char-numeric?` according to the 
     398nonexistent Unicode Numeric property.  That has to be fixed.  Options: 
     399 
     400 1. '''Any.''' `char-numeric?` returns `#t` if the character's 
     401 Numeric_Type property value is other than `None`.  This means that 
     402 many hanzi are both alphabetic and numeric. 
     403 
     404 2. (Omitted, because it does not preserve IEEE Scheme) 
     405 
     406 3. '''ASCII.''' Define `char-numeric?` to return `#t` only for ASCII 
     407 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9.  This retains compatibility witht 
     408 R5RS, and we can still use `char-numeric?` to parse numbers, and 
     409 safely use `(- (char->integer c) (char->integer #\0))` to obtain the 
     410 digit value the character represents.  (Note: R5RS programs that use 
     411 `char-numeric?` to parse numbers will break if we adopt the current 
     412 draft's definition of `char-numeric?`).  Gauche, Gambit, and Chicken 
     413 (without the utf8 egg) work like this. 
     414 
     415 4. '''Digit.''' Define `char-numeric?` as equivalent to the 
     416 Numeric_Digit property (general category value of Nd).  Guile 2.0, 
     417 Kawa, Larceny, Ypsilon, Mosh, and IronScheme work like this. 
     418 
     419 5. '''Number.''' Define `char-numeric?` as equivalent to the Number 
     420 property (general category values of Nd, Nl, No).  Scheme48, Chez, 
     421 and Ikarus work like this. 
     422 
     423  * '''Options:''' any, number, digit, ascii, undecided 
     424  * '''Default:''' ascii 
     425  * '''Preferences:'''  
     426 
     427=== #166 Add predicate and accessors for error objects === 
     428 
     429(Email from Vincent Manis) 
     430 
     431Problem: It's impossible to write a portable error handler that writes 
     432out the ''message'' and ''irritants'' that were passed to `error`. 
     433 
     434This comes about because `error` creates an "implementation-defined 
     435object". I would assume that this hides the whole exception class 
     436hierarchy a WG2 implementation might provide. Since the ''message'' 
     437and ''irritants'' arguments to `error` are presumably living in this 
     438implementation-defined object, it should be simple enough to provide 
     439accessors to extract them, so that the above "portable error handler" 
     440can be written. 
     441 
     442Suggestion: Add the following procedures: 
     443 
     444`(error-object? `''object''`)` 
     445 
     446Returns `#t` if ''object'' is something created by `error`, `#f` 
     447otherwise. Any constraints on type disjointness are up to the 
     448implementation. 
     449 
     450`(error-object-message `''object''`)` 
     451 
     452Returns the message of ''object''. 
     453 
     454`(error-object-irritants `''object''`)` 
     455 
     456Returns a list of the irritants of ''object''. 
     457 
     458  * '''Options:''' manis, none, undecided 
     459  * '''Default:''' none 
     460  * '''Preferences:''' manis 
     461 
     462=== #167 Add constructor for error objects === 
     463 
     464(Email from Vincent Manis) 
     465 
     466Problem: Raising arbitrary objects as exceptions has been found to be 
     467nasty in some other languages (Python and C++ in particular). 
     468 
     469This one is a tad speculative, but I'm reluctant to encourage people 
     470to write things like `(raise 4)`, because of course it doesn't respect 
     471any module boundaries. I think the intent with the descriptions of 
     472`raise` and `raise-continuable` was to allow exception hierarchies to 
     473be added in WG2 without constraining them here. I would suggest adding 
     474a new procedure: 
     475 
     476`(make-error-object `''message''` `''obj'' ...`)` 
     477 
     478to creates the implementation-defined object `error` is supposed to 
     479create, and adding a sentence to the `raise` and `raise-continuable` 
     480entries that says "The effect of applying this procedure to an object 
     481not created via `make-error-object` is implementation-defined." This 
     482allows WG2 to do what it wants regarding exception objects, and to 
     483limit the types of exception objects allowed, without breaking 
     484anything in WG1. `Error` can be defined as: 
     485 
     486{{{ 
     487 (define (error message . objs) 
     488   (raise (apply make-error-object message objs))) 
     489}}} 
     490 
     491 
     492  * '''Options:''' manis, none, undecided 
     493  * '''Default:''' none 
     494  * '''Preferences:''' manis 
     495 
     496=== #169 Add standard-*-port procedures === 
     497 
     498These return the initial values of the corresponding `current-*-port` 
     499procedures, and can be used to access the implementation-provided 
     500standard input, output, and error streams. 
     501 
     502  * '''Options:''' r6rs, none, undecided 
     503  * '''Default:''' none 
     504  * '''Preferences:''' r6rs 
     505 
     506=== #171 Duplicate identifiers in define-record-type === 
     507 
     508What happens if `define-record-type` is specified with two fields that 
     509have the same `accessor` identifiers provided for both fields?  More 
     510generally, we need to say what happens when any two identifiers are 
     511non-unique. 
     512 
     513This ticket deals specifically with the situation where two 
     514identifiers (accessors or mutators) of two field clauses in a 
     515`define-record-type` form are identical. This is not meant to address 
     516field names and what happens or what it means if the field names are 
     517symbolically equivalent but lexically distinct. 
     518 
     519  * '''Options:''' error, unspecified, undecided 
     520  * '''Default:''' unspecified 
     521  * '''Preferences:''' error 
     522 
     523=== #173 Unifying BEGINs === 
     524 
     525In R5RS, there are three kinds of BEGINs: 
     526 
     5271) All subforms are expressions; this can be used wherever an 
     528expression can be used.  (4.2.3) 
     529 
     5302) All subforms are definitions; this can be used wherever an internal 
     531definition can be used.  (5.2.2) 
     532 
     5333) Subforms can be definitions or expressions intermixed in any order; 
     534this can be used only at top level.  (In R7RS we extend this to module 
     535top level as well).  (5.1) 
     536 
     537In particular, 
     538 
     539{{{ 
     540(define (x) 
     541 (define y 32) 
     542 (begin 
     543   (define z 45) 
     544   (set! y z)) 
     545 y) 
     546}}} 
     547 
     548is not licensed by any of these provisions, and consequently is not 
     549valid R5RS Scheme.  Nevertheless, all of my usual Schemes accept the 
     550above definition except Scheme48/scsh and SSCM -- actually, SSCM fails 
     551when you invoke x rather than when you define it.  So I'm proposing 
     552that we unify them for R7RS. 
     553 
     554  * '''Options:''' cowan, r5rs, undecided 
     555  * '''Default:''' r5rs 
     556  * '''Preferences:''' cowan 
     557 
     558=== #174 Safe uses of multiple values === 
     559 
     560Currently, uses of `values` where the values are discarded anyway is 
     561illegal, but all the usual Schemes except SCM and SSCM accept them (I 
     562tested with `begin`).  Should we go with something close to the R6RS 
     563wording? 
     564 
     565"The continuations of all non-final expressions within a sequence of 
     566expressions, such as in `lambda`, `begin`, `let`, `let*`, `letrec`, 
     567`letrec*`, `case`, and `cond` forms, take an arbitrary number of 
     568values." 
     569 
     570The definition of `begin` would need to change too: 
     571 
     572{{{ 
     573(define-syntax begin 
     574  (syntax-rules () 
     575    ((begin exp) 
     576     exp) 
     577    ((begin exp1 exp2 ...) 
     578     (call-with-values 
     579         (lambda () exp1) 
     580       (lambda args 
     581         (begin exp2 ...)))))) 
     582}}} 
     583 
     584  * '''Options:''' safe-values, r5rs, undecided 
     585  * '''Default:''' r5rs 
     586  * '''Preferences:''' safe-values 
     587 
     588=== #45 Record-let syntax and semantics === 
     589 
     590{{{ 
     591(record-let <record-data> ((<variable> <field>) ...) 
     592  <body>) 
     593}}} 
     594 
     595Where each <variable> is filled with the corresponding data <field> 
     596from <record-data> as in a <let> expression, then the <body> is 
     597evaluated with these bindinds added and last expressions is 
     598returned. It is an error if the <record-data> does not contain 
     599corresponding <fields>. 
     600 
     601Notice that this works directly on the data itself and that the data 
     602may contain more fields than the one cited in the record-let 
     603expression allowing code to be reused for inherited records. 
     604 
     605Do we need to be able to check at runtime if a given record data has 
     606a given field ? 
     607 
     608 
     609  * '''Options:''' record-let, none, undecided 
     610  * '''Default:''' none 
     611  * '''Preferences:'''  
     612 
     613=== #172 Multiple returns from `map` === 
     614 
     615R6RS specifies that `map` does not mutate previous results if there 
     616are multiple returns from map. Should we include this language? 
     617 
     618  * '''Options:''' r6rs, unspecified, undecided 
     619  * '''Default:''' unspecified 
     620  * '''Preferences:'''  
     621 
     622=== #178 Shadowing with internal definitions === 
     623 
     624From Andre Von Tonder: 
     625 
     626On p 19, some shadowing problems that would break lexical scope are 
     627declared to be errors.  However, I believe there are other examples 
     628that shold be errors that are not covered by the report. 
     629  
     630In R6RS a more general criterion was used - please see R6RS for 
     631details. 
     632  
     633Here is an example that does not violate the WG1 report but should be 
     634an error becasue it violates lexical scoping.  It does not violate the 
     635WG1 criterion because the meaning of x is not needed to determine 
     636whether (foo x p ) is a definition. 
     637 
     638{{{ 
     639    (let ((x #f)) 
     640      (let-syntax ((foo (syntax-rules (x) 
     641                          ((_ x y) (define y 'outer)) 
     642                          ((_ _ y) (define y 'inner))))) 
     643        (let () 
     644          (foo x p) 
     645          (define x #f) ;; this should be an error because 
     646                        ;; it shadows the previous line where 
     647                        ;; x has already been used in its outer sense 
     648                        ;; during expansion 
     649          p))) 
     650}}} 
     651 
     652Here is another example that WG1 allows but that would cause violation 
     653of lexical scoping, because the macro would be evaluated first and 
     654treat ... as a placeholder in a region where it is shadowed to be the 
     655variable bound to 1: 
     656 
     657{{{ 
     658    (let () 
     659      (define-syntax list-macro 
     660        (syntax-rules () 
     661          ((_ x ...) (list x ...)))) 
     662      (define ... 1)    ;; This shadows ... in previously expanded macro 
     663                        ;; body and will be a violation of lexical scoping 
     664      (list-macro 1 2)) ;; if the last line evaluates to (1 2) 
     665}}} 
     666 
     667OTOH, it is unclear to me if WG1 allows this or not. 
     668 
     669{{{ 
     670    (let ((x #f)) 
     671      (let-syntax ((foo (syntax-rules (x) 
     672                          ((_ x y) (define y 'outer)) 
     673                          ((_ _ y) (define y 'inner))))) 
     674        (let () 
     675          (define x #f) 
     676          (foo x p) 
     677          p))) 
     678}}} 
     679 
     680  * '''Options:''' r6rs, r5rs, tonder, undecided 
     681  * '''Default:''' r5rs 
     682  * '''Preferences:''' tonder 
     683 
     684== WG1 - Modules == 
     685 
     686=== #112 REPL redefinitions === 
     687 
     688R5RS leaves unspecified the semantics of redefining a standard binding 
     689in the REPL.  Do we want to specify semantics, or some set of allowed 
     690behavior for this in the WG1 standard? 
     691 
     692REPLs may allow redefinition.  The sixteen cases that occur are 
     693redefining to/from syntax/non-syntax locally/imported, and the issue 
     694is what happens to previous references to the definition.  The general 
     695possibilities are: 
     696 
     697  1. redefinition signals an error 
     698  2. previous references are overridden (generally not possible if it the previous definition was syntax) 
     699  3. previous references are preserved (indicating a new binding was created, often preferred if replacing non-syntax with syntax to avoid runtime errors) 
     700  4. the semantics are left unspecified 
     701 
     702So all 64 combinations for these 4 values in the following 4x4 matrix 
     703are feasible: 
     704 
     705|| From/To       || import || import syntax || define || define-syntax || 
     706|| import        ||   ?    ||       ?       ||   ?    ||       ?       || 
     707|| import syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     708|| define        ||   ?    ||       ?       ||   ?    ||       ?       || 
     709|| define-syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     710 
     711Not all 64 combinations necessarily make sense.  The default from R5RS 
     712is "unspecified", which means all 16 values are unspecified.  Note in 
     713most implementations there is no such thing as a "reference" to 
     714existing syntax, since macros are expanded once, but this is not the 
     715case for SCM or Wraith Scheme. 
     716 
     717  * '''Proposals:''' 
     718    * '''override:''' override for all 16 values (non-syntax to syntax can break closure references) 
     719    * '''preserve:''' preserve for all 16 values (must always create a new definition, not mutate, contrary to most implementations) 
     720    * '''common:''' most common behavior among implementations - override, except preserve for non-syntax to syntax 
     721    * '''simple:''' override, except unspecified for non-syntax to syntax 
     722    * '''dynamic:''' override, except unspecified for syntax to anything (compatible with SCM/Wraith) 
     723  * '''Options:''' override, preserve, common, dynamic, unspecified, undecided 
     724  * '''Default:''' unspecified 
     725  * '''Preferences:'''  
     726 
     727=== #132 Imports override previous imports? === 
     728 
     729The current draft describes importing different bindings for the same 
     730identifier as "an error."  R6RS explicitly requires this to signal an 
     731error.  Do we want to change this? 
     732 
     733This ticket refers only to modules - the top-level semantics are 
     734decided in ticket #112. 
     735 
     736  * '''Options:''' override, preserve, error, unspecified, undecided 
     737  * '''Default:''' error 
     738  * '''Preferences:'''  
     739 
     740=== #160 Interleaving of imports and code in a module === 
     741 
     742Given 
     743 
     744{{{ 
     745   (module (name) 
     746     (begin c1 ...) 
     747     (import (A)) 
     748     (begin c2 ...) 
     749     (import (B)) 
     750     (begin c3 ...)) 
     751}}} 
     752 
     753the intention, reference implementation, and specification from 
     754Scheme48 on which the syntax was based say that all imports establish 
     755the initial environment and then the code is expanded in order, but 
     756interleaving the imports is conceivable. 
     757 
     758  * '''Options:''' shinn, interleave, unspecified, undecided 
     759  * '''Default:''' shinn 
     760  * '''Preferences:''' unspecified 
     761 
     762=== #163 Allow modules at the REPL? === 
     763 
     764Should users be allowed to enter a `module` form at the REPL? 
     765 
     766Note that there are actually many varying approaches to generating 
     767moduls at runtime, and Scheme48 and Chibi use an out-of-band REPL 
     768operation to create new modules, leaving the `module` binding open. 
     769 
     770  * '''Options:''' yes, no, unspecified, undecided 
     771  * '''Default:''' no 
     772  * '''Preferences:'''  
     773 
     774=== #141 What are the semantics of modules with respect to separate compilation? === 
     775 
     776ModulesShinn says that the bodies of libraries are evaluated 
     777before any of the bodies of the importing library; does that include, 
     778eg, "at compile time" rather than at "run time"?  It's not clear. 
     779 
     780  * '''Options:''' compile-time, unspecified, undecided 
     781  * '''Default:''' undecided 
     782  * '''Preferences:''' compile-time 
     783 
     784=== #158 mutating imports === 
     785 
     786Currently the semantics of calling set! or define 
     787on an imported binding is undefined.  Do we 
     788want to specifically make this an error? 
     789 
     790  * '''Options:''' error, allowed, unspecified, undecided 
     791  * '''Default:''' unspecified 
     792  * '''Preferences:'''  
     793 
     794=== #159 base environments === 
     795 
     796What is the base environment provided by the repl, 
     797scripts, and the result of (scheme-report-environment 7)? 
     798 
     799The intention was the base script environment was empty, 
     800scheme-report-environment was (scheme base), and repls 
     801were an implementation-defined superset thereof, but there 
     802are other options and we need to clarify this. 
     803 
     804  * '''Options:''' shinn, undecided 
     805    * '''shinn:''' intention as described above 
     806  * '''Default:''' shinn 
     807  * '''Preferences:'''  
     808 
     809=== #161 module argument to eval === 
     810 
     811It would be useful to allow modules as an argument to eval in addition 
     812to environments.  This could be done with a special syntax, or just 
     813the module name as a list. 
     814 
     815R6RS provides a procedure `environment` which just 
     816takes a list that looks like an import spec an generates 
     817the corresponding environment. 
     818 
     819  * '''Options:''' r6rs, none, undecided 
     820  * '''Default:''' r6rs 
     821  * '''Preferences:'''  
     822 
     823=== #139 `exit` === 
     824 
     825The ballot statement for #62 said we had voted for `exit` when we 
     826voted for ModulesShinn, but that page doesn't mention `exit`.  So we 
     827need to vote on it. 
     828 
     829  * '''Options:''' yes, no, undecided 
     830  * '''Default:''' yes 
     831  * '''Preferences:'''  
     832 
     833=== #144 strip prefix on import === 
     834 
     835I'm thinking that for importing code that defines its external symbols 
     836as `foo:this`, `foo:that`, and `foo:tother`, there should be a type of 
     837import clause that strips a specified prefix from imported symbols. 
     838This is equivalent to renaming on import or renaming on export, but 
     839less painful, in the same way as the `prefix` import clause does. 
     840 
     841Specific proposal: `(strip-prefix <import-set> <prefix-identifier>)`. 
     842 
     843  * '''Options:''' yes, no, undecided 
     844  * '''Default:''' no 
     845  * '''Preferences:''' undecided 
     846 
     847== WG1 - I/O == 
     848 
     849=== #133 Provide read-line === 
     850 
     851This is an R6RS procedure that was part of PortsCowan, but never 
     852explicitly voted up or down by WG1.  It reads a single line up to a 
     853line delimiter from a given port (the current input by default) and 
     854discards the line delimiter. 
     855 
     856  * '''Options:''' yes, no, undecided 
     857  * '''Default:''' no 
     858  * '''Preferences:''' yes 
     859 
     860=== #170 Add with-error-to-file procedure === 
     861 
     862Since we now have `current-error-port`, arguably we should have 
     863`with-error-to-file` for completeness. 
     864 
     865  * '''Options:''' yes, no, undecided 
     866  * '''Default:''' no 
     867  * '''Preferences:'''  
     868 
     869=== #176 Are string ports exclusively character ports? === 
     870 
     871From scheme-reports discussion list, by John Cowan: 
     872 
     873> Jeronimo Pellegrini scripsit: 
     874> > According to Section 6.7.1, "Conversely, not all character ports are 
     875> > binary ports -- for example, the /string ports/ discussed below".  It 
     876> > is not really clear to wether the document *requires* string ports not 
     877> > to be binary or if it was just an example of a port that *could* be 
     878> > character but not binary. 
     879> 
     880> I haven't thought about it, but I guess it *could* be the latter, if the 
     881> environment provides a default encoding for string ports. 
     882 
     883  * '''Options:''' character-only, unspecified, undecided 
     884  * '''Default:''' unspecified 
     885  * '''Preferences:'''  
     886 
     887=== #177 Distinguish file and string ports? === 
     888 
     889Should there exist predicates that identify string and file ports? 
     890 
     891  * '''Options:''' string-port?, file-port?, both, neither, undecided 
     892  * '''Default:''' neither 
     893  * '''Preferences:'''  
     894 
     895=== #131 Output procedures return value === 
     896 
     897Output procedures (display, write, newline) currently return 
     898unspecified value, do we wish to make them return something (like in 
     899case of an error) or not? 
     900 
     901Need proposals. 
     902 
     903  * '''Options:''' r5rs, undecided 
     904  * '''Default:'''  
     905  * '''Preferences:''' r5rs 
     906 
     907=== #134 Provide flush-output-port === 
     908 
     909This is an R6RS procedure that was part of PortsCowan, but never 
     910explicitly voted up or down by WG1.  It flushes implementation output 
     911buffers on the specified port, the current output port by default. 
     912 
     913  * '''Options:''' yes, no, undecided 
     914  * '''Default:''' no 
     915  * '''Preferences:''' yes 
    719916 
    720917== WG1 - Numerics == 
    721918 
    722 === #79 rational-expt === 
    723  
    724 Often a rational-only exponentiation function is useful; that is, a 
    725 rational number raised to an integer power.  Should we add this 
    726 procedure to the core so that exponentiation is available even if 
    727 inexact rationals are not provided or not imported? 
    728  
    729   * '''Options:''' yes, no, module, wg2, undecided 
     919=== #117 Real numbers have imaginary part #e0 === 
     920 
     921In R6RS, a complex number with imaginary part 0 is only real if the 
     922imaginary part is an exact 0.  In R5RS, this was not true, and the 
     923requirement was simply that `(zero? (imag-part Z))` be true. 
     924 
     925  * '''Options:''' exact-only, any-zero, unspecified, undecided 
     926  * '''Default:''' any-zero 
     927  * '''Preferences:''' exact-only 
     928 
     929Comments: This has many implications in how one defines elementary functions, etc., and I think it's important to treat numbers with an inexact zero imaginary part as non-real 
     930 
     931=== #120 Define the semantics of the transcendental functions more fully === 
     932 
     933R6RS has an extended description of the transcendental functions.  Do 
     934we want to include this? 
     935 
     936TODO: explain the exact diff, why it is desirable, and whether any 
     937reasonable alternatives are possible. 
     938 
     939References: 
     940  * http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.7.3.2 
     941 
     942  * '''Options:''' r6rs, r5rs, undecided 
     943  * '''Default:''' r5rs 
     944  * '''Preferences:''' r6rs 
     945 
     946Scheme and Common Lisp have a long history of trying to do the "right thing" with the (elementary) transcendental functions.  The description of R6RS is short and clear, mathematically, and I see no reason not to adopt it. 
     947 
     948=== #121 The semantics of expt for zero bases has been refined === 
     949 
     950This is a change also made by R6RS. 
     951 
     952R5RS says: 
     953 
     954  Returns z1 raised to the power z2. For z1 /= 0, z1^z2^ = e^z2^ log z1; 0^z^ is 1 if z = 0 and 0 otherwise. 
     955 
     956R6RS says: 
     957 
     958  Returns z1 raised to the power z2. For nonzero z1, this is e^z2^ log z1. 0.0^z^ is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive. For other cases in which the first argument is zero, either an exception is raised [...] or an unspecified number object is returned. 
     959 
     960 
     961  * '''Options:''' r6rs, r5rs, undecided 
     962  * '''Default:''' r5rs 
     963  * '''Preferences:''' R6RS 
     964 
     965Comment:  This is not the complete R6RS description and examples.  I prefer the complete description 
     966 
     967=== #122 Make infinity, NaN, and -0.0 semantics (when supported) consistent with IEEE 754 === 
     968 
     969R5RS does not explicitly describe these values.  We have to decide 
     970whether to require that, if an implementation provides any of these 
     971values, they must be consistent with IEEE 754. 
     972 
     973R6RS both requires these values and requires they be consistent with 
     974IEEE 754. 
     975 
     976  * '''Options:''' ieee-754, unspecified, undecided 
     977  * '''Default:''' unspecified 
     978  * '''Preferences:''' unspecified,ieee-654 
     979 
     980=== #175 Control of significant digits or decimal places in NUMBER->STRING === 
     981 
     982Vincent Manis pleads for a way to write numbers with a specified precision: 
     983 
     984http://lists.scheme-reports.org/pipermail/scheme-reports/2011-May/000709.html 
     985 
     986I (Alaric Snell-Pym) wondered if this should be done via 
     987NUMBER->STRING or via an optional extra argument to ROUND etc 
     988specifying a precision, as a number like `0.01` to get two decimal 
     989places. How to provide significant figures rather than DP without 
     990introducing a base-10 dependency is left as an exercise to the reader 
     991(as is the task of deciding if I'm mad for not wanting a base-10 
     992dependency) 
     993 
     994  * '''Options:''' manis, none, undecided 
     995  * '''Default:''' none 
     996  * '''Preferences:''' undecided 
     997 
     998=== #138 DivisionRiastradh domain === 
     999 
     1000Zero as a divisor aside, what should the domain of the proposed 
     1001procedures be? 
     1002 
     1003 1. Any real numbers? 
     1004 1. Integers only? 
     1005 1. Exact integers only? 
     1006 
     1007  * '''Options:''' reals, integers, exact-integers 
     1008  * '''Default:'''  
     1009  * '''Preferences:''' exact-integers 
     1010 
     1011=== #217 DivisionRiastradh exactness preservation === 
     1012 
     1013What about exactness preservation? 
     1014 
     1015 1. Not exactness preserving 
     1016 1. Exactness preserving unless the implementation can prove that an inexact argument can't affect the result (as in the case of an exact zero dividend and an inexact divisor) 
     1017 1. Exactness preserving in all cases 
     1018 
     1019  * '''Options:''' not-exactness-preserving, exactness-preserving, exactness-preserving-unless 
     1020  * '''Default:'''  
     1021  * '''Preferences:''' exactness-preserving-unless 
     1022 
     1023=== #140 Removing `quotient`, `remainder`, `modulo` === 
     1024 
     1025Are we removing the IEEE Scheme functions `quotient`, `remainder`, and 
     1026`modulo` from WG1 Scheme?  If so, we need a special justification, due 
     1027to the charter text: 
     1028 
     1029> Existing features of IEEE Scheme may be removed only if a strong 
     1030> case can be made that they are fundamentally flawed. Insofar as 
     1031> practical, the language should be backwards compatible with the IEEE 
     1032> standard, the R5RS standard, and an appropriate subset of the R6RS 
     1033> standard. 
     1034 
     1035Here's what DivisionRiastradh says: 
     1036 
     1037> Unfortunately, most programming languages give nondescript names 
     1038> such as DIV(IDE), QUOT(IENT), MOD(ULO), and REM(AINDER) to these 
     1039> operations. The language should make clear to programmers what 
     1040> division operations their programs are performing, especially when 
     1041> negative dividends and divisors can arise, but perhaps may not often 
     1042> arise during testing. 
     1043> 
     1044> [...] 
     1045 
     1046> The R5RS gives the names `quotient` and `remainder` to the 
     1047> truncating division operator pair, and the name `modulo` to the 
     1048> remainder half of the flooring division operator pair. For all these 
     1049> three procedures in the R5RS, the dividend may be any integer, and 
     1050> the divisor may be any nonzero integer. 
     1051 
     1052On the other hand, we may prefer relegating them to a 
     1053backward-compatibility module. 
     1054 
     1055Vote "yes" to keep, "no" to remove, and "module" to relegate to a 
     1056module. 
     1057 
     1058  * '''Options:''' yes, no, module, undecided 
     1059  * '''Default:''' yes 
     1060  * '''Preferences:''' yes,yes,yes 
     1061 
     1062=== #151 Extend `finite?` and `nan?` to non-real values === 
     1063 
     1064R6RS specifies the domain of `finite?` and `nan?` as the real numbers 
     1065only.  I propose that `finite?` return `#t` on a non-real value iff 
     1066both the real part and the imaginary part are finite and not `+nan.0`, 
     1067and that `nan?` return `#t` on a non-real value iff either the real or 
     1068the imaginary part is `+nan.0`. 
     1069 
     1070  * '''Proposals:''' 
     1071    * '''cowan:''' the above description 
     1072  * '''Options:''' cowan, unspecified, undecided 
     1073  * '''Default:''' unspecified 
     1074  * '''Preferences:''' cowan 
     1075 
     1076=== #152 exact-integer-sqrt inconsistent with multiple values module === 
     1077 
     1078R5RS does not actually specify any procedures which return multiple 
     1079values, and so the decision to separate multiple values to a module 
     1080was reasonable.  However, we also voted to make `exact-integer-sqrt`, 
     1081which is in the base module, return multiple values, namely the root 
     1082and the remainder.  That would make the procedure useless unless 
     1083multiple values are provided. 
     1084 
     1085We can either make multiple values not a module, make 
     1086`exact-integer-sqrt` return a list (or single integer) rather than 
     1087multiple values, relegate `exact-integer-sqrt` to a new module, remove 
     1088it altogether, or do nothing and leave the inconsistency. 
     1089 
     1090  * '''Options:''' values-in-core, return-list, return-pair, return-root-only, new-module, remove, nothing, undecided 
     1091  * '''Default:''' nothing 
     1092  * '''Preferences:''' values-in-core,return-root-only 
     1093 
     1094=== #180 Make case and cond clauses into bodies === 
     1095 
     1096Andy Wingo suggests: make the clauses in `case` and `cond` forms 
     1097(without `=>`, naturally) be BODY instances, to allow them to have 
     1098definitions.  It is well defined AFAIK, and costs nothing. 
     1099 
     1100The counter-argument is that it doesn't "look" like the sort of place 
     1101definitions are allowed. 
     1102 
     1103  * '''Options:''' yes, no, undecided 
     1104  * '''Default:''' no 
     1105  * '''Preferences:'''  
     1106 
     1107=== #181 Add WHEN and UNLESS to the base module === 
     1108 
     1109  * '''Options:''' yes, no, undecided 
     1110  * '''Default:''' no 
     1111  * '''Preferences:'''  
     1112 
     1113=== #182 Add WHILE and UNTIL === 
     1114 
     1115These trivial syntaxes add familiarity for new Scheme programmers 
     1116coming from other languages, as will almost always be the case.  LOOP 
     1117is too big and named-LET too alien. 
     1118 
     1119  * '''Options:''' yes, no, undecided 
     1120  * '''Default:''' no 
     1121  * '''Preferences:'''  
     1122 
     1123=== #183 Escaped newline removes following whitespace? === 
     1124 
     1125Andy Wingo suggests the R6RS handling of escaped embedded newlines: 
     1126 
     1127{{{ 
     1128    "asdadf \ 
     1129    asdfadf" 
     1130}}} 
     1131 
     1132in R6RS has the same meaning as "asdf asdfadf".  It allows you to 
     1133nicely indent strings that you need to line-break for width.  I 
     1134suggest that the production 
     1135 
     1136{{{ 
     1137   \ NEWLINE WHITESPACE* 
     1138}}} 
     1139 
     1140within string literals be elided. 
     1141 
     1142Note an alternate method for handling embedded strings with nice 
     1143indentation is scribble syntax. 
     1144 
     1145We voted on various string syntaxes previously but did not 
     1146specifically propose this R6RS extension.  We should have a rationale 
     1147if we don't follow it. 
     1148 
     1149  * '''Options:''' yes, no, undecided 
     1150  * '''Default:''' no 
     1151  * '''Preferences:'''  
     1152 
     1153=== #184 Require CHAR=?, STRING=? etc. to accept arbitrary numbers of arguments? === 
     1154 
     1155R5RS makes a point of specifying that supporting more than two 
     1156arguments is optional.  (Everything not explicitly mentioned is 
     1157optional, so this may have significance.)  R6RS requires accepting 2 
     1158or more arguments.  Currently Racket, Gambit, Guile, Chez, Ikarus, 
     1159Larceny, Ypsilon, Mosh, and Scheme 9 support the feature, whereas 
     1160Gauche, MIT, Chicken, Bigloo, Scheme48/scsh, Kawa, SISC, Chibi, 
     1161STklos, and SSCM don't. 
     1162 
     1163  * '''Options:''' yes, no, undecided 
     1164  * '''Default:''' no 
     1165  * '''Preferences:''' yes 
     1166 
     1167=== #185 Add sixth "centered" division operator === 
     1168 
     1169From the Guile manual: 
     1170 
     1171* Scheme Procedure: centered/ x y 
     1172* Scheme Procedure: centered-quotient x y 
     1173* Scheme Procedure: centered-remainder x y 
     1174 
     1175These procedures accept two real numbers x and y, where the divisor y 
     1176must be non-zero. centered-quotient returns the integer q and 
     1177centered-remainder returns the real number r such that x = q*y + r and 
     1178-|y/2| <= r < |y/2|. centered/ returns both q and r, and is more 
     1179efficient than computing each separately. 
     1180 
     1181Note that centered-quotient returns x/y rounded to the nearest 
     1182integer. When x/y lies exactly half-way between two integers, the tie 
     1183is broken according to the sign of y. If y > 0, ties are rounded 
     1184toward positive infinity, otherwise they are rounded toward negative 
     1185infinity. This is a consequence of the requirement that -|y/2| <= r < 
     1186|y/2|. 
     1187 
     1188Note that these operators are equivalent to the R6RS operators div0, 
     1189mod0, and div0-and-mod0. 
     1190 
     1191--Andy Wingo 
     1192 
     1193Taylor Campbell thinks these are useless.  We should probably have use 
     1194cases for _any_ division operator we include. 
     1195 
     1196  * '''Options:''' yes, no, undecided 
    7301197  * '''Default:''' no 
    7311198  * '''Preferences:''' no 
    7321199 
    733 I don't see what inexact rationals has to do with expt. Current expt can do the proposed operation without difficulty. 
    734  
    735 === #81 What numeric tower variants should be supported? === 
    736  
    737 NumericTower lists a plausible set of ten from fixnums only to the 
    738 full monty.  Which ones should we allow an implementation to provide? 
    739 R5RS requires only fixnums large enough to handle string and vector 
    740 indexes, while R6RS requires the full numeric tower. 
    741  
    742 Vote on '''the minimum level of support''' you want to '''require''' 
    743 (implementations may of course still provide more than this).  I've 
    744 included only the most likely options below, write in other options if 
    745 needed. 
    746  
    747 Note quaternions are a fairly rare numeric type, known to be provided 
    748 only by extensions to [http://www.ccs.neu.edu/home/dorai/squat/squat.html scm] 
    749 and [http://wiki.call-cc.org/eggref/4/quaternions chicken], and thus 
    750 may be difficult for other implementations to support if required. 
    751  
    752   * '''Proposals:''' 
    753     * '''r5rs:''' fixnum (`inexact?` may always be false) 
    754     * '''inexact-only:''' inexact (`exact?` may be the same as `integer?`) 
    755     * '''inexact:''' fixnum, inexact 
    756     * '''rational:''' fixnum, inexact, rational 
    757     * '''complex:''' fixnum, inexact, complex 
    758     * '''r6rs:''' fixnum, inexact, rational, complex 
    759     * '''quaternion:''' fixnum, inexact, rational, complex, quaternion 
    760   * '''Options:''' r5rs, inexact-only, inexact, rational, complex, r6rs, quaternion, undecided 
    761   * '''Default:''' r5rs 
    762   * '''Preferences:''' r5rs,r6rs,undecided 
    763  
    764 === #100 integral division === 
    765  
    766 R5RS provides quotient, modulo and remainder for integral 
    767 division. R6RS extended this with div/mod and div0/mod0. A thorough 
    768 analysis of possible division operations is provided in 
    769 DivisionRiastradh, which includes a proposal for five separate 
    770 division operator pairs.  We need to choose which API we'll provide. 
    771  
    772   * '''Proposals:''' 
    773     * '''riastradh:''' DivisionRiastradh 
    774   * '''Options:''' r5rs, r6rs, riastradh, undecided 
    775   * '''Default:''' r5rs 
    776   * '''Preferences:''' r5rs+div/mod,r5rs,undecided 
    777  
    778 I am not a fan of div0/mod0 in r6rs, and I don't recommend it for wg1.  I would prefer to keep quotient/remainder from r5rs, and add div/mod from r6rs (where modulus is a synonym for mod).  I see these operations as number-theoretic operations, so I would prefer that they apply only to integers. 
    779  
    780 == WG1 - Reader Syntax == 
    781  
    782 === #12 symbol literal extensions === 
    783  
    784 In R5RS, symbols parsed as any sequence of valid symbol characters 
    785 that does not begin with a character that can begin a number.  The 
    786 three exceptions `+`, `-` and `...` are also provided.  This allows 
    787 parsing with only constant lookahead to determine type. 
    788  
    789 R6RS added additional exceptions for symbols beginning with `->`, a 
    790 common idiom, still allowing parsers to determine type with a constant 
    791 lookahead. 
    792  
    793 John Cowan proposes allowing anything that cannot be parsed as a 
    794 number to be a valid symbol.  This removes the special case 
    795 exceptions, but may require arbitrary lookahead. 
    796  
    797 Alex Shinn proposes symbols are any sequence of valid symbol 
    798 characters that does not have a prefix which is a valid number.  This 
    799 removes the special case exceptions, allows constant lookahead, and 
    800 allows extensions to number syntax. 
    801  
    802   * '''Proposals:''' 
    803     * '''r5rs:''' symbols may not begin with `-`, except for `-` itself 
    804     * '''r6rs:''' symbols may not begin with `-[^>]` 
    805     * '''cowan:''' symbols are anything that doesn't parse as a number 
    806     * '''shinn:''' symbols may not begin with a number prefix 
    807   * '''Options:''' r5rs, r6rs, cowan, shinn, undecided 
    808   * '''Default:''' r5rs 
    809   * '''Preferences:''' shinn,r5rs 
    810  
    811 === #84 Need to decide on a list of named character escapes === 
    812  
    813 The WG has voted to have a list of character names. 
    814  
    815 The list in R5RS and the longer list in R6RS are only informative.  I 
    816 suggest adopting the R6RS list and making it normative. 
    817  
    818   * '''Proposals:''' 
    819     * '''r5rs:''' space, newline 
    820     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.6 R6RS Characters] 
    821     * '''shinn:''' space, tab, newline, return, escape, null, alarm, backspace 
    822   * '''Options:''' r5rs, r6rs, shinn 
    823   * '''Default:''' r5rs 
    824   * '''Preferences:''' shinn,r6rs,r5rs 
    825  
    826 === #104 list of mnemonic string escapes === 
    827  
    828 Similar to #84, we need to choose a specific list of mnemonic escapes 
    829 like \n and \t to be recognized in strings. 
    830  
    831   * '''Proposals:''' 
    832     * '''r5rs:''' `\\`, `\"` 
    833     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.7 R6RS Strings] 
    834     * '''shinn:''' `\\`, `\"`, `\t`, `\n`, `\r`, `\e`, `\a`, `\b` 
    835   * '''Options:''' r5rs, r6rs, shinn 
    836   * '''Default:''' r5rs 
    837   * '''Preferences:''' shinn,r6rs,r5rs 
     1200=== #195 Editorial: proposed rewording for `begin` === 
     1201 
     1202The documentation for `begin' specifies that it is a sequential 
     1203construct; but really it splices as well, and also of course it's a 
     1204keyword for the module system currently.  This is inaccurate of the 
     1205spec to say that "begin is for sequencing". 
     1206 
     1207Suggestion: adopt the language of R6RS section 11.4.7. 
     1208 
     1209--Andy Wingo 
     1210 
     1211We should explain somewhere the four kinds of `begin`s: (begin expr 
     1212...), (begin decl ...), top-level begin, and module-top-level begin. 
     1213Note that R7RS like R5RS does not have (begin decl ... expr ...). 
     1214 
     1215Vote `yes` to adopt the R6RS description, modified for differences in 
     1216the language. 
     1217 
     1218  * '''Options:''' yes, no, undecided 
     1219  * '''Default:''' no 
     1220  * '''Preferences:''' yes 
     1221 
     1222=== #198 Make it an error for a procedure mapped by MAP and friends to mutate the result list/string/vector === 
     1223 
     1224This is possibly difficult to enforce, and can break existing R5RS 
     1225programs written in very bad style. 
     1226 
     1227  * '''Options:''' yes, no, undecided 
     1228  * '''Default:''' no 
     1229  * '''Preferences:''' 
     1230 
     1231=== #199 Make it an error for a procedure mapped by MAP and friends to return more than once === 
     1232 
     1233This is possibly difficult to enforce, and can break existing R5RS 
     1234programs. 
     1235 
     1236  * '''Options:''' yes, no, undecided 
     1237  * '''Default:''' no 
     1238  * '''Preferences:'''  
     1239 
     1240=== #200 Completing the blob procedures === 
     1241 
     1242Add `blob`, `blob-map`, `blob-for-each`, and blob conversion functions 
     1243to and from lists/vectors/strings. 
     1244 
     1245  * '''Options:''' yes, no, undecided 
     1246  * '''Default:''' no 
     1247  * '''Preferences:'''  
     1248 
     1249Comment: I have an idea of what `blob`, `blob-for-each`, `blob->list`, `list->blob`, `blob->vector`, and `vector->blob` might do, but not the other functions mentioned; so I vote to have these specific functions (with a better name than blob). 
     1250 
     1251=== #205 Roll partial-blob-copy(!) into blob-copy(!) === 
     1252 
     1253... with extra arguments. 
     1254 
     1255  * '''Options:''' yes, no, undecided 
     1256  * '''Default:''' no 
     1257  * '''Preferences:''' yes 
     1258 
     1259=== #206 Provide read-syntax for blobs === 
     1260 
     1261R6RS provides a `#vu8(...)` read-syntax for bytevectors.  SRFI-4 uses 
     1262`#u8(...)`. 
     1263 
     1264  * '''Options:''' r6rs, srfi-4, none, undecided 
     1265  * '''Default:''' none 
     1266  * '''Preferences:''' srfi-4 
     1267 
     1268=== #207 Editorial: Polar complex numbers are inexact === 
     1269 
     1270Add a note saying that `1@2` and `(make-polar 1 2)` MAY evaluate to an 
     1271inexact complex number. 
     1272 
     1273  * '''Options:''' yes, no, undecided 
     1274  * '''Default:''' no 
     1275  * '''Preferences:'''  
     1276 
     1277=== #208 Is || a valid identifier? === 
     1278 
     1279The grammar in 7.1.1 allows `||` as an <identifier>. However, page 5 
     1280suggests the `|...|` form is only for convenience (e.g. `|foo bar|` is 
     1281equivalent to `foo\x20;bar`). There's no way to normalise `||` to 
     1282anything without the vertical bars that's a valid identifier. Was that 
     1283intentional, or should the rule be 
     1284 
     1285{{{ 
     1286<vertical bar> <symbol element>+ <vertical bar> 
     1287}}} 
     1288 
     1289Vote `remove` to remove the `|...|` syntax altogether. 
     1290 
     1291  * '''Options:''' remove, empty-valid, empty-invalid, undecided 
     1292  * '''Default:''' empty-valid 
     1293  * '''Preferences:''' empty-invalid 
     1294 
     1295=== #191 Include CLOSE-PORT ? === 
     1296 
     1297Should we include `close-port`, as a generic version of 
     1298`close-input-port` and `close-output-port`? 
     1299 
     1300  * '''Options:''' yes, no, undecided 
     1301  * '''Default:''' no 
     1302  * '''Preferences:''' yes 
     1303 
     1304=== #188 Clarify wording of `and` and `or` definitions === 
     1305 
     1306The definitions of `and` and `or` may be slightly confusing. Reword 
     1307them to be more clear. One possible hiccup is that the current 
     1308language permits the return of different false values, while a clearer 
     1309wording may preclude this. 
     1310 
     1311R6RS provides a clearer definition that does not provide wiggle room 
     1312for multiple false values. Should we use that? 
     1313 
     1314  * '''Options:''' yes, no, undecided 
     1315  * '''Default:''' no 
     1316  * '''Preferences:''' yes 
     1317 
     1318=== #187 Clarify duplicate bindings in `let*` === 
     1319 
     1320The language of the standard could clarify that duplicate bindings are 
     1321permitted in the clauses of a `let*`. 
     1322 
     1323  * '''Options:''' yes, no, undecided 
     1324  * '''Default:''' no 
     1325  * '''Preferences:'''  
     1326 
     1327=== #215 initial value argument to make-blob === 
     1328 
     1329`make-blob` should either have an initial value argument, or rationale 
     1330why it is inconsistent with `make-vector` and `make-string`. 
     1331 
     1332Vote `yes` for an initial value argument. 
     1333 
     1334  * '''Options:''' yes, no, undecided 
     1335  * '''Default:''' no 
     1336  * '''Preferences:''' yes 
     1337 
     1338=== #216 Controlling use of reader labels on output === 
     1339 
     1340There are cases when one does not want to output reader labels for 
     1341shared structure, such as when you don't care (and want the output to 
     1342be more legible), or when you know that the time or space requirements 
     1343to construct the table will be too large. 
     1344 
     1345We could offer a parameter to control this, or have a separate 
     1346procedure (e.g. `write/simple`) which doesn't use the reader labels. 
     1347 
     1348Finer grained control may also let use specify a predicate for which 
     1349values are interesting (e.g. never use labels for strings), or only 
     1350use labels for cycles, etc. 
     1351 
     1352  * '''Options:''' parameter, write/simple, none, undecided 
     1353  * '''Default:''' none 
     1354  * '''Preferences:'''