Changes between Version 6 and Version 7 of WG1BallotSnellPym


Ignore:
Timestamp:
06/29/11 21:21:07 (6 years ago)
Author:
alaric
Comment:

Some initial votes

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotSnellPym

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