Changes between Version 5 and Version 6 of WG1BallotHsu


Ignore:
Timestamp:
06/29/11 01:27:20 (6 years ago)
Author:
arcfide
Comment:

Third Ballot

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotHsu

    v5 v6  
    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:''' hsu,snellpym+mutate+inheritance,cowan,medernach,rush,r6rs,srfi-9 
    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,r6rs,snellpym 
    49  
    50 R6RS has a clumsy interface that is corrected, IMO, by Cowan's proposal. 
    51  
    52 === #55 Lazy evaluation === 
    53  
    54 R5RS provides a simple mechanism for easy cases of lazy evaluation. 
    55 It does not support generalized lazy evaluation, because all built-in 
    56 procedures are eager whether they 'need' to be or not.  The relevant 
    57 identifiers are `delay` and `force`; they are not present in IEEE 
    58 Scheme.  SRFI 45 argues that this pair is insufficient for expressing 
    59 common lazy algorithms in a way that preserves tail recursion, and 
    60 adds `lazy` (equivalent to `(delay (force ...))`, but acting 
    61 atomically) and `eager`.  The semantics of `delay` and `force` remain 
    62 downward compatible. 
    63  
    64 Vote `srfi-45` to add just the bindings `lazy` and `eager` in addition 
    65 to `delay` and `force`, not all of the `srfi-45` utilities.  Vote 
    66 `none` to remove `delay` and `force` from the standard. 
    67  
    68   * '''Options:''' r5rs, srfi-45, none, wg2, undecided 
    69   * '''Default:''' r5rs 
    70   * '''Preferences:''' undecided,r5rs,srfi-45,wg2,none 
    71  
    72 === #57 Random Numbers === 
    73  
    74 Random numbers are useful for a wide variety of applications, 
    75 including cryptography, statistics, games, simulations and genetic 
    76 programming.  Do we want to provide an interface to random number 
    77 generation in WG1 Scheme? 
    78  
    79   * '''Proposals:''' 
    80     * '''srfi-27:''' [http://srfi.schemers.org/srfi-27/srfi-27.html SRFI-27] 
    81     * '''cl:''' RandomnessCommonLisp 
    82     * '''cowan:''' RandomCowan 
    83     * '''hsu:''' RandomnessArcfide 
    84   * '''Options:''' srfi-27, cl, cowan, hsu, none, wg2, undecided 
    85   * '''Default:''' none 
    86   * '''Preferences:''' cl,hsu,cowan 
    87  
    88 I tend to think that CL is okay here, but absent that choice, a simpler approach that is flexible is preferable.  
    89  
    90 === #62 Environment Variables === 
    91  
    92 Currently, there is no standard way to communicate with the context 
    93 from which a Scheme program was started.  This has become pretty 
    94 standardized over time: a list of strings ("command-line arguments") 
    95 and a map from strings to strings ("environment variables") on input, 
    96 and a small integer or string on output ("exit value").  Scheme should 
    97 recognize these realities. 
    98  
    99 We have `command-line` and `exit` from ModulesShinn, so the question 
    100 remains if we should add SRFI-98 environment accessors. 
    101  
    102   * '''Options:''' srfi-98, none, wg2, undecided 
    103   * '''Default:''' none 
    104   * '''Preferences:''' srfi-98 
    105  
    106 === #68 "Undefined value" vs. "undefined values" === 
    107  
    108 In R5RS, many procedures and syntax forms return an "undefined value". 
    109 In R6RS, the corresponding convention is to return "undefined values", 
    110 meaning an undefined number (including zero) of undefined values.  How 
    111 shall R7RS go? 
    112  
    113 Vote `r5rs` for a single undefined value, `r6rs` for zero or more 
    114 undefined values, or `zero` for exactly zero values.  Anything other 
    115 than `r5rs` would break R5RS (and IEEE) compatibility. 
    116  
    117   * '''Options:''' r5rs, r6rs, zero, undecided 
    118   * '''Default:''' r5rs 
    119   * '''Preferences:''' r6rs,r5rs 
    120  
    121 === #49 Undefined value API === 
    122  
    123 Assuming a single "undefined" value (dependent on the result of #68), 
    124 users sometimes want to test for this value.  If we enforce a unique 
    125 undefined value, one approach is to generate this value explicitly to 
    126 test against, such as `(void)` provided by some implementations. 
    127 Alternately we could provide a test such as `undefined?`.  Either 
    128 approach breaks compatibility with existing extensions, and may be 
    129 prohibitively difficult to implement for compilers lacking a separate 
    130 undefined value type.  Some programmers also consider testing for this 
    131 value sign of a broken design. 
    132  
    133 Vote `generate` for a `(void)` procedure, `test` for `undefined?`, and 
    134 `both` for both. 
    135  
    136   * '''Options:''' generate, test, both, none, wg2, undecided 
    137   * '''Default:''' none 
    138   * '''Preferences:''' generate 
    139  
    140 Testing for this value is bad practice. Likewise, there is no reason that this procedure must return a single value. Systems like Chez Scheme normalize to this void object, but the point of `(void)` is to enable one to explicitly make a procedure return unspecified values. This is valid whether or not we have zero, one, or any number of unspecified values returned (#68). It is useful regardless, and I would like to have it regardless of the outcome of #68. 
    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,r6rs,equal?,srfi-1 
    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:''' srfi-39,snellpym,cowan 
    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:''' cowan,required,return-false,optional,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:''' cowan,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:''' yes,module 
    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, Chez, 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,module 
    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-closed?,port-open?,both 
    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:''' yes 
    273  
    274 === #88 SRFI 87: => in CASE === 
    275  
    276 SRFI-87 extends `case` with a `=>` clauses, analogous to the use of 
    277 `=>` in `cond` clauses, which allows you to pass the item actually 
    278 matched to a procedure. 
    279  
    280 Do we add this extension? 
    281  
    282   * '''Options:''' yes, no, wg2, undecided 
    283   * '''Default:''' no 
    284   * '''Preferences:''' yes 
    285  
    286 === #89 SRFI 61: COND => with generator and guard === 
    287  
    288 SRFI-61 extends `=>` clauses in `cond` with an optional ''guard'' 
    289 form, such that after the value is generated and found to be true, 
    290 it's further checked against the guard.  If the guard returns `#f` the 
    291 clause fails and processing proceeds to the next clause, otherwise the 
    292 clause is accepted as normal. 
    293  
    294 Do we add this extension? 
    295  
    296   * '''Options:''' yes, no, wg2, undecided 
    297   * '''Default:''' no 
    298   * '''Preferences:''' yes 
    299  
    300 This is a good step towards unifying the syntaxes of various dispatch mechanisms, such as syntax-case, match, and cond. 
    301  
    302 === #90 Multiple values in COND => clauses === 
    303  
    304 Currently, `=>` clauses in `cond` accept a single value from the 
    305 ''generator'' (right-hand side) and pass it to the ''receiver'' 
    306 (left-hand side).  Shall we allow the generator to return multiple 
    307 values and pass them to the receiver?  If both this ticket and #89 
    308 pass, multiple values would also be allowed for generator/guard `cond` 
    309 clauses. 
    310  
    311   * '''Options:''' yes, no, wg2, undecided 
    312   * '''Default:''' no 
    313   * '''Preferences:''' yes 
    314  
    315 === #91 INCLUDE at the REPL === 
    316  
    317 Should we allow `(include "''filename''")` at the REPL?  This is 
    318 distinct from `import` in that it just loads code without altering the 
    319 module structure. 
    320  
    321   * '''Options:''' yes, no, wg2, undecided 
    322   * '''Default:''' no 
    323   * '''Preferences:''' yes 
    324  
    325 === #92 Case-folding flags === 
    326  
    327 The default reader in R7RS will default to case-sensitive, but users 
    328 may wish to override this in some situations.  R6RS allows at the 
    329 top-level #!case-fold and #!no-case-fold read syntax to control the 
    330 case-sensitivity of the current file.  Many existing R5RS 
    331 implementations, on the other hand, use #ci and #cs, with the 
    332 difference that they refer to the next datum only. 
    333  
    334 Note PortsCowan provides a separate means of controlling 
    335 case-sensitivity per-port. 
    336  
    337 Vote `per-datum` for the next-datum-only #ci/#cs syntax. 
    338  
    339   * '''Options:''' r6rs, per-datum, none, wg2, undecided 
    340   * '''Default:''' none 
    341   * '''Preferences:''' r6rs 
    342  
    343 === #116 Source File Character Encoding === 
    344  
    345 The standard currently says nothing about the character encoding 
    346 system of source files.  Do we require this to be a fixed encoding 
    347 such as UTF-8, use an out-of-band specification like the Emacs (and 
    348 Python) `-*- coding: foo -*-` convention, or just leave it 
    349 unspecified? 
    350  
    351   * '''Options:''' utf-8, emacs, unspecified, undecided 
    352   * '''Default:''' none 
    353   * '''Preferences:''' unspecified 
    354  
    355 === #93 Removing string mutability === 
    356  
    357 R6RS relegated `string-set!` to a module, and many modern languages 
    358 tend towards making strings immutable.  Removing entirely, however, 
    359 breaks IEEE Scheme compatibility and should only be considered if you 
    360 believe mutable strings are fundamentally broken. 
    361  
    362 Do we remove `string-set!`?  Vote `yes` to remove, `module` to 
    363 relegate to a module as in R6RS, or `no` to keep as is. 
    364  
    365   * '''Options:''' yes, no, module, undecided 
    366   * '''Default:''' no 
    367   * '''Preferences:''' no 
    368  
    369 === #83 Auxiliary Keywords === 
    370  
    371 In R6RS auxiliary keywords (such as `else` in `cond` and `case` forms) 
    372 are explicitly exported from the `(rnrs base (6))` library.  Do we 
    373 want to bind and export these from the core library? 
    374  
    375 If `else` is bound in the default module, then it must be imported at 
    376 the call site whenever using it in `cond` or it won't match 
    377 hygienically. 
    378  
    379 If `else` is '''not''' bound in the default module, then it must not 
    380 be bound or imported at the call site whenever using it in `cond` or 
    381 it won't match hygienically. 
    382  
    383 Another option is to specify for `cond` and `case` that they match the 
    384 `else` identifier literally, ignoring any hygiene.  This breaks 
    385 compatibility with R5RS and R6RS. 
    386  
    387   * '''Options:''' bound, unbound, unhygienic, undecided 
    388   * '''Preferences:''' bound 
    389  
    390 === #101 exactness and `eqv?`/`equal?` === 
    391  
    392 In R5RS `eqv?`/`equal?` are in some sense the broadest tests for 
    393 equality, comparing structural equality, but also tests for the same 
    394 exactness, so that 
    395  
    396    {{{(equal? 0 0.0) => #f}}} 
    397  
    398 whereas 
    399  
    400    {{{(= 0 0.0) => #t}}} 
    401  
    402 Some users consider this confusing, others sometimes want an `equal?` 
    403 that behaves like `=` for numbers. 
    404  
    405 Do we want to change `equal?` and `eqv?` in this way, or add a 
    406 separate exactness-agnostic procedure?  Vote `yes` to change, 
    407 `equal=?` or `inexact-equal?` for separate procedures of those names 
    408 (plus the analogous `eqv=?` or `inexact-eqv?`), or `no` to leave as 
    409 is.  Alternately, write in a separate name. 
    410  
    411   * '''Options:''' yes, equal=?, inexact-equal?, no, wg2, undecided 
    412   * '''Default:''' no 
    413   * '''Preferences:''' no,equal=?,inexact-equal? 
    414  
    415 There is no reason to eliminate the extra precision when we have a test `=` that handles the less precise test. We can easily make eqv=? if we want, so let's not muck up the standard with something like this. 
    416  
    417 === #102 module syntax name === 
    418  
    419 A bikeshed color issue, we need to choose the 
    420 actual names for the module syntax for the winner 
    421 of #2. 
    422  
    423 `import`, `export` and `include` are fairly universal 
    424 and no alternate is suggested unless someone wants 
    425 to write in a proposal. 
    426  
    427 The enclosing syntax can be called either 
    428 `library` as in R6RS, `module` or some other proposal. 
    429  
    430   * '''Options:''' library, module, undecided 
    431   * '''Default:''' library 
    432   * '''Preferences:''' library 
    433  
    434 I want `module` saved for a purely syntactic entity that doesn't exist at all at runtime. Library is already the closer match from R6RS, so let's use that. 
    435  
    436 === #103 module body syntax name === 
    437  
    438 Similar to #102, we need to choose a name 
    439 for the form to include Scheme code directly 
    440 in a module form.  This can be `body` as in 
    441 the proposal, `begin` or some other name. 
    442  
    443   * '''Options:''' body, begin, scheme, code, undecided 
    444   * '''Default:''' body 
    445   * '''Preferences:''' begin,code,body,scheme 
    446  
    447 === #105 case-insensitive module includes === 
    448  
    449 The `include` module form includes files literally 
    450 with the default case-sensitivity.  An `include-ci` 
    451 form could include files case-insensitively 
    452 without resorting to the reader hacks proposed in 
    453 #92, allowing existing R5RS libraries to be used 
    454 without modification. 
    455  
    456   * '''Options:''' yes, no, wg2, undecided 
    457   * '''Default:''' no 
    458   * '''Preferences:''' yes 
    459  
    460 This can be implemented with a reader parameter and unhygienic macros, but absent those, this makes sense, and it is generally useful. 
    461  
    462 === #106 conditional code selection === 
    463  
    464 Users invariably want some way to conditionally select code depending 
    465 on the implementation and/or feature set available. CondExpandCowan 
    466 allows conditional expansion in the style of SRFI-0 within the module language. 
    467 [http://srfi.schemers.org/srfi-0/srfi-0.html SRFI-0] provides 
    468 `cond-expand`, [http://srfi.schemers.org/srfi-103/srfi-103.html SRFI-103] 
    469 provides a library naming extension, and numerous other personal hacks exist. 
    470  
    471 Do we want to include something along these lines in WG1 Scheme? 
    472  
    473   * '''Proposals:''' 
    474     * '''cowan:''' CondExpandCowan 
    475     * '''srfi-0:''' `cond-expand` only defined as a top-level module form 
    476     * '''srfi-103:''' the search path extension used by R6RS implementations 
    477   * '''Options:''' cowan, srfi-0, srfi-103, none, wg2, undecided 
    478   * '''Default:''' none 
    479   * '''Preferences:''' wg2,none 
    480  
    481 None of these are good enough to put in a Small Scheme. Let WG2 have it. 
    482  
    483 === #108 immutable data interface === 
    484  
    485 R5RS specifies literal data in source code as immutable, but otherwise 
    486 provides no way to generate or introspect immutable data. 
    487  
    488 One proposal is given in ImmutableData, providing `mutable?`, 
    489 `make-immutable` and `immutable->mutable`. 
    490  
    491 Racket, for which all pairs are immutable in the default language, 
    492 needs some way to generate shared and cyclic data structures at 
    493 runtime, and provides the `shared` syntax for this.  It also has an 
    494 `immutable?` utility as the complement to `mutable?` above. 
    495  
    496   * '''Proposals:''' 
    497     * '''medernach:''' ImmutableData 
    498     * '''racket:''' `shared`, `immutable?` ([http://docs.racket-lang.org/reference/shared.html]) 
    499   * '''Options:''' medernach, racket, no, undecided 
    500   * '''Default:''' no 
    501   * '''Preferences:''' undecided 
    502  
    503 I think this needs more discussion and proofs. 
    504  
    505 === #111 require `equal?` to return `#t` if `eqv?` does === 
    506  
    507 Currently `equal?` is strictly broader than `eqv?` except in the 
    508 pathological case of comparing the same circular list with itself, for 
    509 which `eqv?` returns true and `equal?` may loop infinitely.  We could 
    510 explicitly require `equal?` to check and return `#t` in this case, 
    511 which most implementations do as a performance hack anyway. 
    512  
    513   * '''Options:''' yes, no, undecided 
    514   * '''Default:''' no 
    515   * '''Preferences:''' yes 
    516  
    517 == WG1 - Exceptions == 
    518  
    519 === #18 exception system === 
    520  
    521 R6RS provided a detailed exception system with support for raising and 
    522 catching exceptions, using a hierarchy of exception types. 
    523  
    524 Do we use this, or parts of it, or a new exception system?  The `r6rs` 
    525 option is just for the core exception handling. 
    526  
    527   * '''Proposals:''' 
    528     * '''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` 
    529     * '''cowan:''' ExceptionHandlingCowan 
    530   * '''Options:''' cowan, r6rs, wg2, none, undecided 
    531   * '''Default:''' none 
    532   * '''Preferences:''' r6rs,wg2 
    533  
    534 Better to go with R6RS than yet another system. Either that, or let WG2 have it. 
    535  
    536 === #19 when to throw an error === 
    537  
    538 R5RS defines many things as "is an error" without any specification of 
    539 what happens in that situation.  R6RS goes to the opposite extreme and 
    540 specifies as much as possible what exceptions are raised when. 
    541  
    542 Taking into account the system provided by ticket #18, we need to come 
    543 up with guidelines for when exceptions should be raised, and clarify 
    544 which R5RS "error" situations should raise an exception or be left 
    545 unspecified. 
    546  
    547 R5RS specifies only 3 situations where an error is required to be 
    548 signalled, leaving most situations unspecified as described in 
    549 ErrorSituations. 
    550  
    551   * '''Options:''' r5rs, r6rs, undecided 
    552   * '''Default:''' r5rs 
    553   * '''Preferences:''' undecided 
    554  
    555 == WG1 - I/O == 
     37  * '''Default:''' srfi-9 
     38  * '''Preferences:''' hsu,gleckler,wg2,none,srfi-9 
     39 
     40Rationale: SRFI-9 is flawed by the filtering constructor and a lack of extensibility in its syntax, but represents a good minimal set of features that are found everywhere. 
    55641 
    55742=== #28 binary I/O ports === 
     
    56146be mixed on the different port types? 
    56247 
    563 PortsCowan provides binary port operations along with other 
    564 extensions. 
     48BinaryPortsCowan provides binary port operations, being a mild revision of the relevant parts of PortsCowan. 
    56549 
    56650R6RS provides an entirely new I/O system, as well as a separate 
     
    57559aspects will be merged as needed. 
    57660 
     61WG1 voted weakly in favor of PortsCowan before. 
     62 
    57763  * '''Proposals:'''  
    57864    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
    57965    * '''r6rs-simple:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.3 R6RS Simple I/O] 
    58066    * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
    581     * '''cowan:''' PortsCowan (subset relevant to binary I/O) 
     67    * '''cowan:''' BinaryPortsCowan 
    58268  * '''Options:''' r6rs, r6rs-simple, srfi-91, cowan, none, undecided 
    58369  * '''Default:''' none 
    58470  * '''Preferences:''' undecided 
    58571 
    586 I have not had enough time to read over the history of these things, and I need more time. 
    587  
    588 === #29 port encodings === 
    589  
    590 Do we support encoding and decoding text from ports with different 
    591 character encoding systems?  Different end-of-line conventions? 
    592 Different normalizations?  How are encoding errors handled? 
    593  
    594   * '''Proposals:'''  
    595     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
    596     * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
    597     * '''cowan:''' PortsCowan (subset relevant to port encodings) 
    598   * '''Options:''' r6rs, srfi-91, cowan, none, undecided 
     72Rationale: I think we still need more time on this. R6RS' biggest trouble is its I/O system,  
     73and I don't want the same mistake being made again. We need more effort into this domain first by more people. 
     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 
     103 
     104Rationale: While there are advantages to being unbound, unbound is still too limited and  
     105the advantages do not outweight the disadvantages. Bound has a few disadvantages,  
     106but we gain much more flexibility and the advantages just outweigh the disadvantages.  
     107Unbound limits what you can do, while Bound presents only some minor inconvenience that  
     108sometimes occurs, but that is easily worked around in ways that aren't hacky. 
     109 
     110=== #3 module naming convention === 
     111 
     112We need a naming convention for the core modules and standard 
     113libraries of the new module system. 
     114 
     115The existing break down is based on John Cowan's earlier proposal of 
     116factorings in items #71, #72, #73, #74, #75, #76, #77, as well as an 
     117I/O module breakdown in PortsCowan.  There have been various tickets 
     118proposing changing this, so we are re-opening the ticket. 
     119 
     120  * '''Proposals:''' 
     121    * '''draft-1:''' the first draft 
     122    * '''r5rs:''' one single module 
     123    * '''r6rs:''' no proposal yet 
     124    * '''cowan:''' ModuleFactoringCowan 
     125    * '''gleckler:''' ModuleFactoringGleckler 
     126    * '''shinn:''' ModuleFactoringShinn 
     127    * '''medernach:''' ModuleFactoringMedernach 
     128  * '''Options:''' draft-1, r5rs, r6rs, cowan, shinn, medernach, undecided 
     129  * '''Default:''' draft-1 
     130  * '''Preferences:''' undecided 
     131 
     132Rationale: I have not had enough time to look this over. 
     133 
     134= New Ballot Items = 
     135 
     136== WG1 - Core == 
     137 
     138=== #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? === 
     139 
     140Now that we have blobs, we have to decide what to call them.  R6RS 
     141uses bytevector, SRFI-4 and SRFI-68 uses u8vector, while the original 
     142WG1 proposal used blob (which is therefore the default). 
     143 
     144  * '''Options:''' blob, bytevector, byte-vector, u8vector, octet-vector, undecided 
     145  * '''Default:''' blob 
     146  * '''Preferences:''' bytevector,u8vector,octet-vector,byte-vector,blob 
     147 
     148Rationale: Blob doesn't give enough information to the reader and feels strange,  
     149despite its terseness. Bytevector very accurately describes the data structure we 
     150are dealing with. No matter how you decide to treat those bytes, we are still  
     151dealing with a vector of bytes, not a vector of 3 bits or something else.  
     152I disagree that there is confusion on how to use a bytevector just because the  
     153word "byte" appears in the name. On the other hand, blob gives no hints on  
     154how to use the structure at all, or even what sort of things might be available. 
     155 
     156=== #118 Simple literals must be explicitly delimited. === 
     157 
     158In R5RS syntax such as `#t#f` is left unspecified - some readers may 
     159parse this as the true literal followed by false.  R6RS requires 
     160identifiers, characters, booleans, number objects, and `.` to be 
     161terminated with a "delimiter" or by the end of input. 
     162 
     163References: 
     164  * http://scheme-punks.org/wiki/index.php?title=ERR5RS:Lexical_Syntax 
     165  * http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002649.html 
     166 
     167  * '''Options:''' delimited, unspecified, undecided 
     168  * '''Default:''' unspecified 
     169  * '''Preferences:''' delimited,unspecified 
     170 
     171Rationale: I prefer to create less ambiguity here. 
     172 
     173=== #119 Whether to treat # as a delimiter. === 
     174 
     175In R5RS `foo#f` is a valid identifier, whereas R6RS requires `#` to 
     176act as a delimiter, so that this would parse as the identifier `foo` 
     177followed by the false literal. 
     178 
     179  * '''Options:'''  delimiter, no, undecided 
     180  * '''Default:''' no 
     181  * '''Preferences:''' delimiter 
     182 
     183Rationale: We have ways such as with the vertical bar of enclosing data,  
     184so there is no reason to make something like # confusing to the reader.  
     185`|foo#f|` is clear, while `foo#f` is not, so let's make # a delimiter. 
     186 
     187=== #123 Extend unquote and unquote-splicing to multiple arguments === 
     188 
     189This is a change also made by R6RS (and CL). 
     190 
     191References: 
     192  * http://lists.scheme-reports.org/pipermail/scheme-reports/2011-April/000448.html 
     193  * http://www.rhinocerus.net/forum/lang-scheme/98742-quasiquote-syntax-rules-macro.html 
     194  * http://www.mail-archive.com/guile-user@gnu.org/msg03899.html 
     195 
     196  * '''Options:''' multiple, single, undecided 
     197  * '''Default:''' single 
     198  * '''Preferences:''' multiple 
     199 
     200Rationale: Convincing arguments have been made as to why this is a good thing on the  
     201mailing list, and there are too many unsolved issues if we leave it as single.  
     202 
     203=== #124 Nested quasiquote semantics === 
     204 
     205References: 
     206  * http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.17 
     207  * http://lists.nongnu.org/archive/html/chicken-hackers/2010-12/msg00008.html 
     208 
     209  * '''Proposals:''' 
     210    * '''r5rs:''' unspecified 
     211    * '''r6rs:''' strict and multiple (implies multiple for #123) 
     212    * '''chicken:''' strict at level 0 (option 2 in second reference) 
     213    * '''strict:''' strict at all levels (R6RS with single for #123) 
     214  * '''Options:''' r5rs, r6rs, chicken, strict, undecided 
     215  * '''Default:''' r5rs 
     216  * '''Preferences:''' r6rs,strict 
     217 
     218Rationale: R6RS makes things much easier to work with in this regard. We should  
     219adopt this. I have encountered situations where this makes a great deal of sense, 
     220especially in macro writing. 
     221 
     222=== #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) === 
     223 
     224This is a change also made by R6RS, specifically: 
     225 
     226> A quasiquote expression may return either fresh, mutable objects or literal structure 
     227> for any structure that is constructed at run time during the evaluation of the expression. 
     228> Portions that do not need to be rebuilt are always literal 
     229 
     230  * '''Options:''' r6rs, r5rs, undecided 
     231  * '''Default:''' r5rs 
     232  * '''Preferences:''' r6rs 
     233 
     234Rationale: This gives more flexibility to the implementation when dealing with quasiquote. 
     235 
     236=== #126 Partly specify the mutability of the values of quasiquote structures === 
     237 
     238This is a change also made by R6RS. 
     239 
     240  * '''Options:''' r6rs, r5rs, undecided 
     241  * '''Default:''' r5rs 
     242  * '''Preferences:''' r6rs 
     243 
     244Rationale: R6RS is an improvement in this regard.  
     245 
     246=== #127 Specify the dynamic environment of the ''before'' and ''after'' procedures of dynamic-wind === 
     247 
     248R5RS is slightly ambiguous, saying 
     249 
     250> BEFORE is called whenever execution enters the dynamic extent of the 
     251> call to THUNK and AFTER is called whenever it exits that dynamic 
     252> extent. 
     253 
     254without saying clearly whether ''before'' and ''after'' themselves are 
     255called before or after the dynamic extent is entered or exited. 
     256 
     257  * '''Proposals:''' 
     258    * '''outside:''' called outside the dynamic extent (R6RS) 
     259    * '''inside:''' called inside the dynamic extent 
     260    * '''unspecified:''' R5RS 
     261  * '''Options:''' outside, inside, unspecified, undecided 
     262  * '''Default:''' unspecified 
     263  * '''Preferences:''' outside,inside,unspecified 
     264 
     265Rationale: Making them outside is how I always think of these, and it makes  
     266more sense syntactically, visually, and in terms of programming convenience. 
     267Either way, we should specify one or the other, and not leave this unspecified. 
     268 
     269=== #135 let-values and let*-values === 
     270 
     271These R6RS procedures were part of #77 (modularization of multiple 
     272values), but were never explicitly voted up or down by WG1, so I'm 
     273opening a new ticket for them. 
     274 
     275  * '''Options:''' yes, no, module, wg2, undecided 
     276  * '''Default:''' no 
     277  * '''Preferences:''' yes,wg2,module 
     278 
     279Rationale: These are simple and very useful constructs that are in common use  
     280throughout. They are an excellent addition to the multiple values abstraction 
     281and should certainly be included. 
     282 
     283=== #137 Current-seconds semantics still open === 
     284 
     285In issue #70, WG1 voted to make `current-seconds` an optional 
     286procedure, but there is no guidance about what it returns. 
     287 
     288If we choose to specify this further, the big question is whether or 
     289not to include leap seconds - i.e. do we specify it as TAI or POSIX 
     290time (the choice of the epoch itself is less controversial and 
     291defaults to the POSIX epoch).  TAI time has the advantage that it 
     292measures real, unambiguous time, and two calls to current-seconds more 
     293than a second apart are guaranteed to actually differ.  POSIX time has 
     294the advantage of bug-for-bug compatibility with POSIX systems - the 
     295times are ambiguous, but they already have to deal with that. 
     296 
     297The other issue is whether to return an integral number of seconds and 
     298lose the ability to specify subsecond real times, or return an inexact 
     299real (flonum) number of seconds and have to deal with variable 
     300precision depending on the date. 
     301 
     302TimeCowan is equivalent to the `posix-integer` option, and in addition 
     303changes the name to `current-posix-second`. 
     304 
     305  * '''Proposals:''' 
     306    * '''cowan:''' TimeCowan 
     307    * '''posix-integer:''' POSIX time as an exact integer value 
     308    * '''posix-flonum:''' POSIX time as an inexact real value 
     309    * '''tai-integer:''' TAI time as an exact integer value 
     310    * '''tai-flonum:''' TAI time as an inexact real value 
     311  * '''Options:''' cowan, unspecified, undecided, none 
     312  * '''Default:''' unspecified 
     313  * '''Preferences:''' tai-flonum,tai-integer,cowan,posix-flonum,posix-integer 
     314 
     315Rationale: We should make it clear when we are dealing in POSIX, and otherwise  
     316we should avoid bugs, even if they are common. Floating points are more useful, 
     317in this case. 
     318 
     319=== #147 Allow literal file spec lists in include and include-ci === 
     320 
     321This could allow implementation-specific extensions to support files 
     322don't have character-string names.  On the other hand, such names 
     323probably shouldn't be used as source files, and there are other ways 
     324to support this. 
     325 
     326  * '''Options:''' yes, no, undecided 
     327  * '''Default:''' no 
     328  * '''Preferences:''' undecided,no,yes 
     329 
     330Rationale: We should not prohibit extensions to `include`, but we should only  
     331define string based names. 
     332 
     333=== #148 Allow include-ci at top level === 
     334 
     335Currently `include-ci` is allowed as a module declaration but not at top level, 
     336as `include` is. 
     337 
     338  * '''Options:''' yes, no, undecided 
     339  * '''Default:''' no 
     340  * '''Preferences:''' yes 
     341 
     342Rationale: This is an oversight. 
     343 
     344=== #149 blob ports === 
     345 
     346We've voted to add string ports, which are character ports backed by 
     347Scheme strings.  Since we have blobs another potential extension is 
     348blob ports, which binary ports backed by blobs.  These are described 
     349in PortsCowan, but it's unclear if they were specifically voted for or 
     350against in the previous ballot. 
     351 
     352  * '''Options:''' cowan, none, undecided 
    599353  * '''Default:''' none 
     354  * '''Preferences:''' cowan 
     355 
     356Rationale: We want a way to get a port abstraction on blobs. 
     357 
     358=== #150 cond-expand at top level === 
     359 
     360Currently `cond-expand` is only valid as a module declaration.  Should 
     361we allow it at top level in a program? 
     362 
     363  * '''Options:''' yes, no, undecided 
     364  * '''Default:''' no 
     365  * '''Preferences:''' no 
     366 
     367Rationale: `cond-expand` is a bad and flawed construct that should not  
     368be made available to the user. Its appearance in a module declaration is  
     369somewhat forgivable as a static construct, but it's use at anything other  
     370than inside of a module declaration is, IMO, very bad. We should not  
     371encourage its use.  
     372 
     373=== #153 Renaming blob procedures === 
     374 
     375The blob procedures don't follow the same system as the rest.  I 
     376propose these changes: 
     377 
     378{{{ 
     379copy-blob => blob-copy 
     380copy-blob! => blob-copy! 
     381partial-blob => blob-copy-partial 
     382copy-partial-blob! -> blob-copy-partial! 
     383}}} 
     384 
     385Note this is modulo the choice of "blob" or "bytevector" 
     386or whichever. 
     387 
     388  * '''Options:''' new, original, remove, undecided 
     389  * '''Default:''' original 
     390  * '''Preferences:''' new,original 
     391 
     392Rationale: Consistent naming is important here, and the hierarchical naming 
     393policy makes much more sense. 
     394 
     395=== #154 Physical newline in a string equivalent to \n (that is, U+000A) === 
     396 
     397R5RS leaves this situation undefined, but R6RS, CL, and most languages 
     398that allow it (C does not) treat physical newline and escaped newline 
     399as equivalent, even if the local representation of line endings is 
     400\r\n or U+0085 or what not.  Another possibility is to treat string literals 
     401broken across lines as errors. 
     402 
     403  * '''Options:''' unix, local, error, unspecified, undecided 
     404  * '''Default:''' unspecified 
     405  * '''Preferences:''' unix,unspecified 
     406 
     407Rationale: We should not allow the ambiguity that a string may contain  
     408different data when loaded on two different operating systems, so the  
     409treatment of newlines should be transparent. If an user wants to actually  
     410have a string with a CRLF line ending, then we can configure this at a  
     411port or output level. We should not do this at the reader level. This is  
     412also in keeping with standard practice in other languages, as the ticket  
     413mentions. Deviating from this is just confusing. 
     414 
     415=== #155 Make recursively defined code an explicit error === 
     416 
     417Allowing examples like these will make code-walkers (including 
     418compilers and interpreters) excessively complicated: 
     419 
     420#1=(begin (display #\x) . #1#) 
     421 
     422(lambda #2=(a b c #2#) ...) 
     423 
     424(+ . #3=(1 2 3 . #3#)) 
     425 
     426  * '''Options:''' error, unspecified, undecided 
     427  * '''Default:''' unspecified 
     428  * '''Preferences:''' unspecified 
     429 
     430Rationale: Making this an error makes things more complicated, not  
     431less, and it makes life more difficult on naive implementations. Leave 
     432this unspecified. 
     433 
     434=== #156 Replace "an error is signalled" with "an implementation-dependent object is raised as if by `raise`" === 
     435 
     436The following situations are described in draft 1 (and R5RS) with "an 
     437error is signalled": 
     438 
     439 1. The ''file-spec'' given to `call-with-input-file`, 
     440 `call-with-output-file`, `open-input-file`, or `open-output-file` 
     441 represents a file that cannot be opened. 
     442 
     443 2. An end of file is read from a port by `read` after the beginning 
     444 of an object's external representation, but the external 
     445 representation is incomplete and therefore not parsable. 
     446 
     447I propose that in both cases the implementation be required to raise 
     448an exception as if by applying `raise` (that is, non-continuably) to 
     449an implementation-defined object, which means it can be caught by the 
     450R7RS exception system.  Note that there is no requirement to create a 
     451fresh object. 
     452 
     453  * '''Options:''' signal, unspecified, undecided 
     454  * '''Default:''' unspecified 
     455  * '''Preferences:''' signal 
     456 
     457Rationale: Regardless of what is raised, the exception must be capturable by  
     458the exception system. I think it makes more sense to put this at the beginning 
     459and continue to use "an error is signalled," but with a more precise  
     460explanation of what this means. 
     461 
     462=== #162 Remove DELAY and FORCE altogether === 
     463 
     464They are present in R4RS and R5RS, but not IEEE Scheme (which is our 
     465baseline).  There are problems with a straightforward implementation 
     466that SRFI 45 fixes, but we voted down SRFI 45.  Given that, we should 
     467consider removing them from the standard altogether.  (Of course this 
     468does not mean compliant implementations can't provide them, it just 
     469means they won't be in a standard module.) 
     470 
     471Since the inconsistency was raised and people are going so far as 
     472to remove these, we can entertain votes for SRFI-45's `lazy` again. 
     473 
     474  * '''Options:''' remove, keep, lazy, undecided 
     475  * '''Default:''' keep 
    600476  * '''Preferences:''' undecided 
    601477 
    602 I need more time for this one. 
    603  
    604 === #31 custom ports === 
    605  
    606 Do we provide a mechanism for custom ports, on which for instance 
    607 string ports could be created? 
    608  
    609 R6RS as well as a number of Scheme implementations provide custom 
    610 ports with various APIs. 
    611  
    612   * '''Proposals:'''  
    613     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
    614   * '''Options:''' r6rs, none 
     478Rationale: I think this warrants more work before a final vote. 
     479 
     480=== #164 Meaning of char-numeric? === 
     481 
     482The current draft, like R6RS, defines `char-numeric?` according to the 
     483nonexistent Unicode Numeric property.  That has to be fixed.  Options: 
     484 
     485 1. '''Any.''' `char-numeric?` returns `#t` if the character's 
     486 Numeric_Type property value is other than `None`.  This means that 
     487 many hanzi are both alphabetic and numeric. 
     488 
     489 2. (Omitted, because it does not preserve IEEE Scheme) 
     490 
     491 3. '''ASCII.''' Define `char-numeric?` to return `#t` only for ASCII 
     492 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9.  This retains compatibility witht 
     493 R5RS, and we can still use `char-numeric?` to parse numbers, and 
     494 safely use `(- (char->integer c) (char->integer #\0))` to obtain the 
     495 digit value the character represents.  (Note: R5RS programs that use 
     496 `char-numeric?` to parse numbers will break if we adopt the current 
     497 draft's definition of `char-numeric?`).  Gauche, Gambit, and Chicken 
     498 (without the utf8 egg) work like this. 
     499 
     500 4. '''Digit.''' Define `char-numeric?` as equivalent to the 
     501 Numeric_Digit property (general category value of Nd).  Guile 2.0, 
     502 Kawa, Larceny, Ypsilon, Mosh, and IronScheme work like this. 
     503 
     504 5. '''Number.''' Define `char-numeric?` as equivalent to the Number 
     505 property (general category values of Nd, Nl, No).  Scheme48, Chez, 
     506 and Ikarus work like this. 
     507 
     508  * '''Options:''' any, number, digit, ascii, undecided 
     509  * '''Default:''' ascii 
     510  * '''Preferences:''' number,digit,ascii,any 
     511 
     512Rationale: Number seems like the better and more general choice. 
     513 
     514=== #166 Add predicate and accessors for error objects === 
     515 
     516(Email from Vincent Manis) 
     517 
     518Problem: It's impossible to write a portable error handler that writes 
     519out the ''message'' and ''irritants'' that were passed to `error`. 
     520 
     521This comes about because `error` creates an "implementation-defined 
     522object". I would assume that this hides the whole exception class 
     523hierarchy a WG2 implementation might provide. Since the ''message'' 
     524and ''irritants'' arguments to `error` are presumably living in this 
     525implementation-defined object, it should be simple enough to provide 
     526accessors to extract them, so that the above "portable error handler" 
     527can be written. 
     528 
     529Suggestion: Add the following procedures: 
     530 
     531`(error-object? `''object''`)` 
     532 
     533Returns `#t` if ''object'' is something created by `error`, `#f` 
     534otherwise. Any constraints on type disjointness are up to the 
     535implementation. 
     536 
     537`(error-object-message `''object''`)` 
     538 
     539Returns the message of ''object''. 
     540 
     541`(error-object-irritants `''object''`)` 
     542 
     543Returns a list of the irritants of ''object''. 
     544 
     545  * '''Options:''' manis, none, undecided 
     546  * '''Default:''' none 
     547  * '''Preferences:'''  
     548 
     549=== #167 Add constructor for error objects === 
     550 
     551(Email from Vincent Manis) 
     552 
     553Problem: Raising arbitrary objects as exceptions has been found to be 
     554nasty in some other languages (Python and C++ in particular). 
     555 
     556This one is a tad speculative, but I'm reluctant to encourage people 
     557to write things like `(raise 4)`, because of course it doesn't respect 
     558any module boundaries. I think the intent with the descriptions of 
     559`raise` and `raise-continuable` was to allow exception hierarchies to 
     560be added in WG2 without constraining them here. I would suggest adding 
     561a new procedure: 
     562 
     563`(make-error-object `''message''` `''obj'' ...`)` 
     564 
     565to creates the implementation-defined object `error` is supposed to 
     566create, and adding a sentence to the `raise` and `raise-continuable` 
     567entries that says "The effect of applying this procedure to an object 
     568not created via `make-error-object` is implementation-defined." This 
     569allows WG2 to do what it wants regarding exception objects, and to 
     570limit the types of exception objects allowed, without breaking 
     571anything in WG1. `Error` can be defined as: 
     572 
     573{{{ 
     574 (define (error message . objs) 
     575   (raise (apply make-error-object message objs))) 
     576}}} 
     577 
     578 
     579  * '''Options:''' manis, none, undecided 
     580  * '''Default:''' none 
     581  * '''Preferences:'''  
     582 
     583=== #169 Add standard-*-port procedures === 
     584 
     585These return the initial values of the corresponding `current-*-port` 
     586procedures, and can be used to access the implementation-provided 
     587standard input, output, and error streams. 
     588 
     589  * '''Options:''' r6rs, none, undecided 
    615590  * '''Default:''' none 
    616591  * '''Preferences:''' r6rs 
    617592 
    618 This needs more discussion. I recall hearing some complaints about the R6RS system, but I do think that custom ports are universal enough to warrant consideration. 
    619  
    620 == WG1 - Libraries == 
    621  
    622 === #36 hash-tables === 
    623  
    624 R6RS and SRFI-69 both provide hash-table interfaces.  Do we provide 
    625 either of these, or try to provide some primitives on which efficient 
    626 hash-tables can be implemented? 
    627  
    628   * '''Options:''' r6rs, srfi-69, no, wg2, undecided 
    629   * '''Default:''' no 
     593Rationale: These are very common and should be provided. 
     594 
     595=== #171 Duplicate identifiers in define-record-type === 
     596 
     597What happens if `define-record-type` is specified with two fields that 
     598have the same `accessor` identifiers provided for both fields?  More 
     599generally, we need to say what happens when any two identifiers are 
     600non-unique. 
     601 
     602This ticket deals specifically with the situation where two 
     603identifiers (accessors or mutators) of two field clauses in a 
     604`define-record-type` form are identical. This is not meant to address 
     605field names and what happens or what it means if the field names are 
     606symbolically equivalent but lexically distinct. 
     607 
     608  * '''Options:''' error, unspecified, undecided 
     609  * '''Default:''' unspecified 
     610  * '''Preferences:''' error 
     611 
     612Rationale: This situation doesn't make sense, so it should be an error. 
     613 
     614=== #173 Unifying BEGINs === 
     615 
     616In R5RS, there are three kinds of BEGINs: 
     617 
     6181) All subforms are expressions; this can be used wherever an 
     619expression can be used.  (4.2.3) 
     620 
     6212) All subforms are definitions; this can be used wherever an internal 
     622definition can be used.  (5.2.2) 
     623 
     6243) Subforms can be definitions or expressions intermixed in any order; 
     625this can be used only at top level.  (In R7RS we extend this to module 
     626top level as well).  (5.1) 
     627 
     628In particular, 
     629 
     630{{{ 
     631(define (x) 
     632 (define y 32) 
     633 (begin 
     634   (define z 45) 
     635   (set! y z)) 
     636 y) 
     637}}} 
     638 
     639is not licensed by any of these provisions, and consequently is not 
     640valid R5RS Scheme.  Nevertheless, all of my usual Schemes accept the 
     641above definition except Scheme48/scsh and SSCM -- actually, SSCM fails 
     642when you invoke x rather than when you define it.  So I'm proposing 
     643that we unify them for R7RS. 
     644 
     645  * '''Options:''' cowan, r5rs, undecided 
     646  * '''Default:''' r5rs 
     647  * '''Preferences:''' cowan 
     648 
     649Rationale: Having three different begins and two of which are not splicing 
     650while one is, but can only appear at the top-level, is confusing and not  
     651in the spirit of Scheme. 
     652 
     653=== #174 Safe uses of multiple values === 
     654 
     655Currently, uses of `values` where the values are discarded anyway is 
     656illegal, but all the usual Schemes except SCM and SSCM accept them (I 
     657tested with `begin`).  Should we go with something close to the R6RS 
     658wording? 
     659 
     660"The continuations of all non-final expressions within a sequence of 
     661expressions, such as in `lambda`, `begin`, `let`, `let*`, `letrec`, 
     662`letrec*`, `case`, and `cond` forms, take an arbitrary number of 
     663values." 
     664 
     665The definition of `begin` would need to change too: 
     666 
     667{{{ 
     668(define-syntax begin 
     669  (syntax-rules () 
     670    ((begin exp) 
     671     exp) 
     672    ((begin exp1 exp2 ...) 
     673     (call-with-values 
     674         (lambda () exp1) 
     675       (lambda args 
     676         (begin exp2 ...)))))) 
     677}}} 
     678 
     679  * '''Options:''' safe-values, r5rs, undecided 
     680  * '''Default:''' r5rs 
     681  * '''Preferences:''' safe-values 
     682 
     683Rationale: Most everyone does this, it is pretty much a de facto  
     684standard and we should respect it. 
     685 
     686=== #45 Record-let syntax and semantics === 
     687 
     688{{{ 
     689(record-let <record-data> ((<variable> <field>) ...) 
     690  <body>) 
     691}}} 
     692 
     693Where each <variable> is filled with the corresponding data <field> 
     694from <record-data> as in a <let> expression, then the <body> is 
     695evaluated with these bindinds added and last expressions is 
     696returned. It is an error if the <record-data> does not contain 
     697corresponding <fields>. 
     698 
     699Notice that this works directly on the data itself and that the data 
     700may contain more fields than the one cited in the record-let 
     701expression allowing code to be reused for inherited records. 
     702 
     703Do we need to be able to check at runtime if a given record data has 
     704a given field ? 
     705 
     706 
     707  * '''Options:''' record-let, none, undecided 
     708  * '''Default:''' none 
     709  * '''Preferences:''' record-let,undecided 
     710 
     711Rationale: This is underspecified at the moment and should be cleaned up,  
     712but I think it should be in here, as it is a common thing to want to do. 
     713 
     714=== #172 Multiple returns from `map` === 
     715 
     716R6RS specifies that `map` does not mutate previous results if there 
     717are multiple returns from map. Should we include this language? 
     718 
     719  * '''Options:''' r6rs, unspecified, undecided 
     720  * '''Default:''' unspecified 
    630721  * '''Preferences:''' r6rs 
    631722 
    632 === #113 directory contents === 
    633  
    634 We've decided to add file-exists? and delete-file, 
    635 essential for a large class of scripts, but still 
    636 have no way to get a list of files in a directory. 
    637 Do we want to provide an interface to this? 
     723Rationale: This provides a measure of stability to `map` that we would  
     724not otherwise have. 
     725 
     726=== #178 Shadowing with internal definitions === 
     727 
     728From Andre Von Tonder: 
     729 
     730On p 19, some shadowing problems that would break lexical scope are 
     731declared to be errors.  However, I believe there are other examples 
     732that shold be errors that are not covered by the report. 
     733  
     734In R6RS a more general criterion was used - please see R6RS for 
     735details. 
     736  
     737Here is an example that does not violate the WG1 report but should be 
     738an error becasue it violates lexical scoping.  It does not violate the 
     739WG1 criterion because the meaning of x is not needed to determine 
     740whether (foo x p ) is a definition. 
     741 
     742{{{ 
     743    (let ((x #f)) 
     744      (let-syntax ((foo (syntax-rules (x) 
     745                          ((_ x y) (define y 'outer)) 
     746                          ((_ _ y) (define y 'inner))))) 
     747        (let () 
     748          (foo x p) 
     749          (define x #f) ;; this should be an error because 
     750                        ;; it shadows the previous line where 
     751                        ;; x has already been used in its outer sense 
     752                        ;; during expansion 
     753          p))) 
     754}}} 
     755 
     756Here is another example that WG1 allows but that would cause violation 
     757of lexical scoping, because the macro would be evaluated first and 
     758treat ... as a placeholder in a region where it is shadowed to be the 
     759variable bound to 1: 
     760 
     761{{{ 
     762    (let () 
     763      (define-syntax list-macro 
     764        (syntax-rules () 
     765          ((_ x ...) (list x ...)))) 
     766      (define ... 1)    ;; This shadows ... in previously expanded macro 
     767                        ;; body and will be a violation of lexical scoping 
     768      (list-macro 1 2)) ;; if the last line evaluates to (1 2) 
     769}}} 
     770 
     771OTOH, it is unclear to me if WG1 allows this or not. 
     772 
     773{{{ 
     774    (let ((x #f)) 
     775      (let-syntax ((foo (syntax-rules (x) 
     776                          ((_ x y) (define y 'outer)) 
     777                          ((_ _ y) (define y 'inner))))) 
     778        (let () 
     779          (define x #f) 
     780          (foo x p) 
     781          p))) 
     782}}} 
     783 
     784  * '''Options:''' r6rs, r5rs, tonder, undecided 
     785  * '''Default:''' r5rs 
     786  * '''Preferences:''' r6rs,undecided 
     787 
     788Rationale: I prefer the R6RS language here, as it scales well and is unambiguous. 
     789 
     790== WG1 - Modules == 
     791 
     792=== #112 REPL redefinitions === 
     793 
     794R5RS leaves unspecified the semantics of redefining a standard binding 
     795in the REPL.  Do we want to specify semantics, or some set of allowed 
     796behavior for this in the WG1 standard? 
     797 
     798REPLs may allow redefinition.  The sixteen cases that occur are 
     799redefining to/from syntax/non-syntax locally/imported, and the issue 
     800is what happens to previous references to the definition.  The general 
     801possibilities are: 
     802 
     803  1. redefinition signals an error 
     804  2. previous references are overridden (generally not possible if it the previous definition was syntax) 
     805  3. previous references are preserved (indicating a new binding was created, often preferred if replacing non-syntax with syntax to avoid runtime errors) 
     806  4. the semantics are left unspecified 
     807 
     808So all 64 combinations for these 4 values in the following 4x4 matrix 
     809are feasible: 
     810 
     811|| From/To       || import || import syntax || define || define-syntax || 
     812|| import        ||   ?    ||       ?       ||   ?    ||       ?       || 
     813|| import syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     814|| define        ||   ?    ||       ?       ||   ?    ||       ?       || 
     815|| define-syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     816 
     817Not all 64 combinations necessarily make sense.  The default from R5RS 
     818is "unspecified", which means all 16 values are unspecified.  Note in 
     819most implementations there is no such thing as a "reference" to 
     820existing syntax, since macros are expanded once, but this is not the 
     821case for SCM or Wraith Scheme. 
    638822 
    639823  * '''Proposals:''' 
    640     *  '''cowan:''' DirectoryPortsCowan 
    641     *  '''directory-files:''' return a list of all files in the dir 
    642     *  '''directory-streams:''' [http://www.scsh.net/docu/html/man-Z-H-4.html#node_sec_3.3 SCSH directory stream interface] 
    643   * '''Options:''' directory-files, directory-streams, no, wg2, undecided 
    644   * '''Default:''' no 
     824    * '''override:''' override for all 16 values (non-syntax to syntax can break closure references) 
     825    * '''preserve:''' preserve for all 16 values (must always create a new definition, not mutate, contrary to most implementations) 
     826    * '''common:''' most common behavior among implementations - override, except preserve for non-syntax to syntax 
     827    * '''simple:''' override, except unspecified for non-syntax to syntax 
     828    * '''dynamic:''' override, except unspecified for syntax to anything (compatible with SCM/Wraith) 
     829  * '''Options:''' override, preserve, common, dynamic, unspecified, undecided 
     830  * '''Default:''' unspecified 
     831  * '''Preferences:''' common,simple,unspecified,undecided 
     832 
     833Rationale: We should go with the common case, which I think is overwhelmingly chosen and used.  
     834Either that or we can leave things unspecified, but this results in an ambiguous REPL,  
     835which I thought the WG1 was trying to avoid as much as possible. 
     836 
     837=== #132 Imports override previous imports? === 
     838 
     839The current draft describes importing different bindings for the same 
     840identifier as "an error."  R6RS explicitly requires this to signal an 
     841error.  Do we want to change this? 
     842 
     843This ticket refers only to modules - the top-level semantics are 
     844decided in ticket #112. 
     845 
     846  * '''Options:''' override, preserve, error, unspecified, undecided 
     847  * '''Default:''' error 
     848  * '''Preferences:''' error,undecided 
     849 
     850Rationale: Two imports into the same scope is essentially equivalent to two definitions with  
     851the same identifier as the target binding. Imports at the same level should be imported to the  
     852same scope, rather than introducing some new, implied scope. 
     853 
     854=== #160 Interleaving of imports and code in a module === 
     855 
     856Given 
     857 
     858{{{ 
     859   (module (name) 
     860     (begin c1 ...) 
     861     (import (A)) 
     862     (begin c2 ...) 
     863     (import (B)) 
     864     (begin c3 ...)) 
     865}}} 
     866 
     867the intention, reference implementation, and specification from 
     868Scheme48 on which the syntax was based say that all imports establish 
     869the initial environment and then the code is expanded in order, but 
     870interleaving the imports is conceivable. 
     871 
     872  * '''Options:''' shinn, interleave, unspecified, undecided 
     873  * '''Default:''' shinn 
     874  * '''Preferences:''' shinn,undecided,interleave 
     875 
     876Rationale: Interleaving complicates the semantics. We should keep  
     877with imports as being at the top level. 
     878 
     879=== #163 Allow modules at the REPL? === 
     880 
     881Should users be allowed to enter a `module` form at the REPL? 
     882 
     883Note that there are actually many varying approaches to generating 
     884moduls at runtime, and Scheme48 and Chibi use an out-of-band REPL 
     885operation to create new modules, leaving the `module` binding open. 
     886 
     887  * '''Options:''' yes, no, unspecified, undecided 
     888  * '''Default:''' no 
     889  * '''Preferences:''' yes,undecided,unspecified,no 
     890 
     891Rationale: This is something that is very convenient to do, and can be  
     892implemented even on implementations that leave the module binding open. 
     893 
     894=== #141 What are the semantics of modules with respect to separate compilation? === 
     895 
     896ModulesShinn says that the bodies of libraries are evaluated 
     897before any of the bodies of the importing library; does that include, 
     898eg, "at compile time" rather than at "run time"?  It's not clear. 
     899 
     900  * '''Options:''' compile-time, unspecified, undecided 
     901  * '''Default:''' undecided 
    645902  * '''Preferences:''' undecided 
    646903 
    647 == WG1 - Macros == 
    648  
    649 === #48 let-syntax === 
    650  
    651 `let-syntax` and `letrec-syntax` has known ambiguities in their 
    652 behavior. We have the option of altering the semantics to correct this 
    653 behavior, defining which behavior we intend, or removing `let-syntax` 
    654 entirely.  We could also leave this ambiguity unspecified. 
    655  
    656 The question of whether or not to introduce a new lexical scope 
    657 (i.e. whether internal `define`s are visible outside the `let-syntax`) 
    658 is straightforward. 
    659  
    660 If we don't introduce a new lexical scope, the question arises whether 
    661 or not internal `define-syntax` forms are allowed and whether they 
    662 apply to the body of the `let-syntax`, forms following the 
    663 `let-syntax`, or both. 
    664  
    665 If internal `define-syntax` applies to the body, we may also wish to 
    666 specify what happens when said `define-syntax` redefines an identifier 
    667 bound by the enclosing `let-syntax`.  This varies by implementation 
    668 and may be difficult for macro expanders to change, so is left 
    669 unspecified in the proposals below. 
     904Rationale: I think we need to introduce a clearer concept of what happens at  
     905compile time and what happens at run time, and understand the differences here. 
     906As such, I do not think that we should finalize this vote yet. 
     907 
     908=== #158 mutating imports === 
     909 
     910Currently the semantics of calling set! or define 
     911on an imported binding is undefined.  Do we 
     912want to specifically make this an error? 
     913 
     914  * '''Options:''' error, allowed, unspecified, undecided 
     915  * '''Default:''' unspecified 
     916  * '''Preferences:''' error,undecided,unspecified 
     917 
     918Rationale: Immutable imports is something that we definitely want to have,  
     919and is something that many implementations use. We should ensure, at least, 
     920that we maintain compatibility with those systems that use such semantics. 
     921 
     922=== #159 base environments === 
     923 
     924What is the base environment provided by the repl, 
     925scripts, and the result of (scheme-report-environment 7)? 
     926 
     927The intention was the base script environment was empty, 
     928scheme-report-environment was (scheme base), and repls 
     929were an implementation-defined superset thereof, but there 
     930are other options and we need to clarify this. 
     931 
     932  * '''Options:''' shinn, undecided 
     933    * '''shinn:''' intention as described above 
     934  * '''Default:''' shinn 
     935  * '''Preferences:''' undecided,shinn 
     936 
     937Rationale: We should have more discussion on this. 
     938 
     939=== #161 module argument to eval === 
     940 
     941It would be useful to allow modules as an argument to eval in addition 
     942to environments.  This could be done with a special syntax, or just 
     943the module name as a list. 
     944 
     945R6RS provides a procedure `environment` which just 
     946takes a list that looks like an import spec an generates 
     947the corresponding environment. 
     948 
     949  * '''Options:''' r6rs, none, undecided 
     950  * '''Default:''' r6rs 
     951  * '''Preferences:''' r6rs,undecided,none 
     952 
     953Rationale: R6RS' `environment` is extremely useful and works well. 
     954 
     955=== #139 `exit` === 
     956 
     957The ballot statement for #62 said we had voted for `exit` when we 
     958voted for ModulesShinn, but that page doesn't mention `exit`.  So we 
     959need to vote on it. 
     960 
     961  * '''Options:''' yes, no, undecided 
     962  * '''Default:''' yes 
     963  * '''Preferences:''' yes,undecided,no 
     964 
     965Rationale: Very useful, yes. 
     966 
     967=== #144 strip prefix on import === 
     968 
     969I'm thinking that for importing code that defines its external symbols 
     970as `foo:this`, `foo:that`, and `foo:tother`, there should be a type of 
     971import clause that strips a specified prefix from imported symbols. 
     972This is equivalent to renaming on import or renaming on export, but 
     973less painful, in the same way as the `prefix` import clause does. 
     974 
     975Specific proposal: `(strip-prefix <import-set> <prefix-identifier>)`. 
     976 
     977  * '''Options:''' yes, no, undecided 
     978  * '''Default:''' no 
     979  * '''Preferences:''' yes,undecided,no 
     980 
     981Rationale: This is very useful, and a common form among implementation 
     982module systems. 
     983 
     984== WG1 - I/O == 
     985 
     986=== #133 Provide read-line === 
     987 
     988This is an R6RS procedure that was part of PortsCowan, but never 
     989explicitly voted up or down by WG1.  It reads a single line up to a 
     990line delimiter from a given port (the current input by default) and 
     991discards the line delimiter. 
     992 
     993  * '''Options:''' yes, no, undecided 
     994  * '''Default:''' no 
     995  * '''Preferences:''' yes,undecided,no 
     996 
     997Rationale: very common and very useful. 
     998 
     999=== #170 Add with-error-to-file procedure === 
     1000 
     1001Since we now have `current-error-port`, arguably we should have 
     1002`with-error-to-file` for completeness. 
     1003 
     1004  * '''Options:''' yes, no, undecided 
     1005  * '''Default:''' no 
     1006  * '''Preferences:''' yes,undecided,no 
     1007 
     1008Rationale: Useful, and it rounds things out. 
     1009 
     1010=== #176 Are string ports exclusively character ports? === 
     1011 
     1012From scheme-reports discussion list, by John Cowan: 
     1013 
     1014> Jeronimo Pellegrini scripsit: 
     1015> > According to Section 6.7.1, "Conversely, not all character ports are 
     1016> > binary ports -- for example, the /string ports/ discussed below".  It 
     1017> > is not really clear to wether the document *requires* string ports not 
     1018> > to be binary or if it was just an example of a port that *could* be 
     1019> > character but not binary. 
     1020> 
     1021> I haven't thought about it, but I guess it *could* be the latter, if the 
     1022> environment provides a default encoding for string ports. 
     1023 
     1024  * '''Options:''' character-only, unspecified, undecided 
     1025  * '''Default:''' unspecified 
     1026  * '''Preferences:''' character-only,undecided,unspecified 
     1027 
     1028Rationale: We don't want to confuse binary and character ports. Strings should  
     1029only have characters (code points) as their underlying subelement, and we  
     1030should not confuse that with byte vectors or the like. 
     1031 
     1032=== #177 Distinguish file and string ports? === 
     1033 
     1034Should there exist predicates that identify string and file ports? 
     1035 
     1036  * '''Options:''' string-port?, file-port?, both, neither, undecided 
     1037  * '''Default:''' neither 
     1038  * '''Preferences:''' both,neither,string-port?,file-port?,undecided 
     1039 
     1040Rationale: It makes sense to have them, and we should have both or neither  
     1041rather than only one or the other, but some systems don't provide these.  
     1042 
     1043=== #131 Output procedures return value === 
     1044 
     1045Output procedures (display, write, newline) currently return 
     1046unspecified value, do we wish to make them return something (like in 
     1047case of an error) or not? 
     1048 
     1049Need proposals. 
     1050 
     1051  * '''Options:''' r5rs, undecided 
     1052  * '''Default:'''  
     1053  * '''Preferences:''' r5rs,undecided 
     1054 
     1055Rationale: We should stick with the unspecified error, there is no good reason  
     1056to change this. 
     1057 
     1058=== #134 Provide flush-output-port === 
     1059 
     1060This is an R6RS procedure that was part of PortsCowan, but never 
     1061explicitly voted up or down by WG1.  It flushes implementation output 
     1062buffers on the specified port, the current output port by default. 
     1063 
     1064  * '''Options:''' yes, no, undecided 
     1065  * '''Default:''' no 
     1066  * '''Preferences:''' yes,undecided,no 
     1067 
     1068Rationale: This is an extremely useful procedure and is crucial in some  
     1069applications. 
     1070 
     1071== WG1 - Numerics == 
     1072 
     1073=== #117 Real numbers have imaginary part #e0 === 
     1074 
     1075In R6RS, a complex number with imaginary part 0 is only real if the 
     1076imaginary part is an exact 0.  In R5RS, this was not true, and the 
     1077requirement was simply that `(zero? (imag-part Z))` be true. 
     1078 
     1079  * '''Options:''' exact-only, any-zero, unspecified, undecided 
     1080  * '''Default:''' any-zero 
     1081  * '''Preferences:''' exact-only,any-zero,unspecified,undecided 
     1082 
     1083Rationale: I prefer the exact form. 
     1084 
     1085=== #120 Define the semantics of the transcendental functions more fully === 
     1086 
     1087R6RS has an extended description of the transcendental functions.  Do 
     1088we want to include this? 
     1089 
     1090TODO: explain the exact diff, why it is desirable, and whether any 
     1091reasonable alternatives are possible. 
     1092 
     1093References: 
     1094  * http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.7.3.2 
     1095 
     1096  * '''Options:''' r6rs, r5rs, undecided 
     1097  * '''Default:''' r5rs 
     1098  * '''Preferences:''' r6rs,undecided,r5rs 
     1099 
     1100Rationale: We should clear this up and try to improve the descriptions of these things 
     1101where we can, but we should still discuss exactly what we want to include and how/why. 
     1102 
     1103=== #121 The semantics of expt for zero bases has been refined === 
     1104 
     1105This is a change also made by R6RS. 
     1106 
     1107R5RS says: 
     1108 
     1109  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. 
     1110 
     1111R6RS says: 
     1112 
     1113  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. 
     1114 
     1115 
     1116  * '''Options:''' r6rs, r5rs, undecided 
     1117  * '''Default:''' r5rs 
     1118  * '''Preferences:''' r6rs,undecided,r5rs 
     1119 
     1120Rationale: I prefer the more detailed description. 
     1121 
     1122=== #122 Make infinity, NaN, and -0.0 semantics (when supported) consistent with IEEE 754 === 
     1123 
     1124R5RS does not explicitly describe these values.  We have to decide 
     1125whether to require that, if an implementation provides any of these 
     1126values, they must be consistent with IEEE 754. 
     1127 
     1128R6RS both requires these values and requires they be consistent with 
     1129IEEE 754. 
     1130 
     1131  * '''Options:''' ieee-754, unspecified, undecided 
     1132  * '''Default:''' unspecified 
     1133  * '''Preferences:''' ieee-754,undecided,unspecified 
     1134 
     1135Rationale: I don't think there is a good reason to deviate here, but I also  
     1136think that we could benefit from some more discussion on this if there are  
     1137good examples to why deviating from ieee-754 improves things. 
     1138 
     1139=== #175 Control of significant digits or decimal places in NUMBER->STRING === 
     1140 
     1141Vincent Manis pleads for a way to write numbers with a specified precision: 
     1142 
     1143http://lists.scheme-reports.org/pipermail/scheme-reports/2011-May/000709.html 
     1144 
     1145I (Alaric Snell-Pym) wondered if this should be done via 
     1146NUMBER->STRING or via an optional extra argument to ROUND etc 
     1147specifying a precision, as a number like `0.01` to get two decimal 
     1148places. How to provide significant figures rather than DP without 
     1149introducing a base-10 dependency is left as an exercise to the reader 
     1150(as is the task of deciding if I'm mad for not wanting a base-10 
     1151dependency) 
     1152 
     1153  * '''Options:''' manis, none, undecided 
     1154  * '''Default:''' none 
     1155  * '''Preferences:''' none,undecided,manis 
     1156 
     1157Rationale: This is better tackled by more complete formatting procedures 
     1158or some additional rounding operation on strings. We should not clutter  
     1159`number->string` to provide this specific functionality. 
     1160 
     1161=== #138 DivisionRiastradh domain === 
     1162 
     1163Zero as a divisor aside, what should the domain of the proposed 
     1164procedures be? 
     1165 
     1166 1. Any real numbers? 
     1167 1. Integers only? 
     1168 1. Exact integers only? 
     1169 
     1170  * '''Options:''' reals, integers, exact-integers 
     1171  * '''Default:'''  
     1172  * '''Preferences:''' undecided 
     1173 
     1174Rationale: I want to see more discussion on this. 
     1175 
     1176=== #217 DivisionRiastradh exactness preservation === 
     1177 
     1178What about exactness preservation? 
     1179 
     1180 1. Not exactness preserving 
     1181 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) 
     1182 1. Exactness preserving in all cases 
     1183 
     1184  * '''Options:''' not-exactness-preserving, exactness-preserving, exactness-preserving-unless 
     1185  * '''Default:'''  
     1186  * '''Preferences:''' undecided 
     1187 
     1188Rationale: I want to see more discussion on this before I make my decision. 
     1189 
     1190=== #140 Removing `quotient`, `remainder`, `modulo` === 
     1191 
     1192Are we removing the IEEE Scheme functions `quotient`, `remainder`, and 
     1193`modulo` from WG1 Scheme?  If so, we need a special justification, due 
     1194to the charter text: 
     1195 
     1196> Existing features of IEEE Scheme may be removed only if a strong 
     1197> case can be made that they are fundamentally flawed. Insofar as 
     1198> practical, the language should be backwards compatible with the IEEE 
     1199> standard, the R5RS standard, and an appropriate subset of the R6RS 
     1200> standard. 
     1201 
     1202Here's what DivisionRiastradh says: 
     1203 
     1204> Unfortunately, most programming languages give nondescript names 
     1205> such as DIV(IDE), QUOT(IENT), MOD(ULO), and REM(AINDER) to these 
     1206> operations. The language should make clear to programmers what 
     1207> division operations their programs are performing, especially when 
     1208> negative dividends and divisors can arise, but perhaps may not often 
     1209> arise during testing. 
     1210> 
     1211> [...] 
     1212 
     1213> The R5RS gives the names `quotient` and `remainder` to the 
     1214> truncating division operator pair, and the name `modulo` to the 
     1215> remainder half of the flooring division operator pair. For all these 
     1216> three procedures in the R5RS, the dividend may be any integer, and 
     1217> the divisor may be any nonzero integer. 
     1218 
     1219On the other hand, we may prefer relegating them to a 
     1220backward-compatibility module. 
     1221 
     1222Vote "yes" to keep, "no" to remove, and "module" to relegate to a 
     1223module. 
     1224 
     1225  * '''Options:''' yes, no, module, undecided 
     1226  * '''Default:''' yes 
     1227  * '''Preferences:''' module,yes,undecided,no 
     1228 
     1229Rationale: I think we can reasonably relegate these, but I'm hesitant to  
     1230remove them completely, since they tend to be very commonly used. More  
     1231discussion is a good thing here. 
     1232 
     1233=== #151 Extend `finite?` and `nan?` to non-real values === 
     1234 
     1235R6RS specifies the domain of `finite?` and `nan?` as the real numbers 
     1236only.  I propose that `finite?` return `#t` on a non-real value iff 
     1237both the real part and the imaginary part are finite and not `+nan.0`, 
     1238and that `nan?` return `#t` on a non-real value iff either the real or 
     1239the imaginary part is `+nan.0`. 
    6701240 
    6711241  * '''Proposals:''' 
    672     * '''hsu:''' LetSyntaxArcfide 
    673     * '''remove:''' remove both of these forms from the standard 
    674     * '''lexical:''' introduces a new lexical contour 
    675     * '''define:''' allows splicing `define`/`begin` 
    676     * '''syntax:''' allows `define-syntax` 
    677     * '''syntax-body:''' allows `define-syntax` only applying to the body 
    678     * '''syntax-follows:'''  allows `define-syntax` only applying to following forms 
    679   * '''Options:''' hsu, remove, lexical, define, syntax, syntax-body, syntax-follows, unspecified, undecided 
     1242    * '''cowan:''' the above description 
     1243  * '''Options:''' cowan, unspecified, undecided 
    6801244  * '''Default:''' unspecified 
    681   * '''Preferences:''' LetSyntaxArcfide,lexical,syntax-follows 
    682  
    683 I am voting for LetSyntaxArcfide with the understanding that it is proposing a new approach to `let-syntax` functionality rather than being a fully finished product. I believe that `let-syntax` is not very useful if it does not splice, and not very correct if it does, so I don`t like having it around. 
    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 
    704  
    705 Getting these with special meanings makes sense, but if an user puts them in the literals list, then we should not surprise them by breaking. However, if we do break, then an error should be the result, and not some silent failure. 
    706  
    707 == WG1 - Modules == 
    708  
    709 === #3 module naming convention === 
    710  
    711 We need a naming convention for the core modules and standard 
    712 libraries of the new module system. 
    713  
    714 In R5RS everything is effectively in a single module.  R6RS provides a 
    715 much more fine-grained breakdown of modules which could be 
    716 retro-fitted to the bindings we include in our standard. 
    717  
    718 John Cowan has proposed a number of module factorings in items #71, 
    719 #72, #73, #74, #75, #76, #77, as well as an I/O module breakdown in 
    720 PortsCowan. 
    721  
    722 Since the naming and breakdown must be internally consistent I'm 
    723 grouping these into a single ballot item.  Members desiring to put 
    724 forth a new proposal should specify where all bindings belong, or 
    725 specify a subset of the bindings and default the rest to some other 
    726 proposal. 
    727  
    728 Note some ballots specify explicitly whether or not the bindings in 
    729 question are intended to be in a module or the core language.  In 
    730 these cases we still need to decide to which module they belong. 
    731 Where specific votes contradict general factoring proposals, the 
    732 specific vote wins. 
    733  
    734   * '''Proposals:''' 
    735     * '''r5rs:''' one single module 
    736     * '''r6rs:''' 
    737     * '''cowan:''' #71, #72, #73, #74, #75, #76, #77 
    738   * '''Options:''' r5rs, r6rs, cowan, undecided 
    739   * '''Default:''' r5rs 
     1245  * '''Preferences:''' undecided,cowan,unspecified 
     1246 
     1247Rationale: I don't know the ramifications of this, and I would like more  
     1248discussion on this. 
     1249 
     1250=== #152 exact-integer-sqrt inconsistent with multiple values module === 
     1251 
     1252R5RS does not actually specify any procedures which return multiple 
     1253values, and so the decision to separate multiple values to a module 
     1254was reasonable.  However, we also voted to make `exact-integer-sqrt`, 
     1255which is in the base module, return multiple values, namely the root 
     1256and the remainder.  That would make the procedure useless unless 
     1257multiple values are provided. 
     1258 
     1259We can either make multiple values not a module, make 
     1260`exact-integer-sqrt` return a list (or single integer) rather than 
     1261multiple values, relegate `exact-integer-sqrt` to a new module, remove 
     1262it altogether, or do nothing and leave the inconsistency. 
     1263 
     1264  * '''Options:''' values-in-core, return-list, return-pair, return-root-only, new-module, remove, nothing, undecided 
     1265  * '''Default:''' nothing 
     1266  * '''Preferences:''' values-in-core,new-module,nothing,undecided,return-root-only,remove,return-pair,return-list 
     1267 
     1268Rationale: I don't want to have any procedure in the language that uses lists/pairs as intermediate  
     1269container constructs, as I am offended (in some ways) by that sort of conflation of the use  
     1270of lists. Values should be in the core. 
     1271 
     1272=== #180 Make case and cond clauses into bodies === 
     1273 
     1274Andy Wingo suggests: make the clauses in `case` and `cond` forms 
     1275(without `=>`, naturally) be BODY instances, to allow them to have 
     1276definitions.  It is well defined AFAIK, and costs nothing. 
     1277 
     1278The counter-argument is that it doesn't "look" like the sort of place 
     1279definitions are allowed. 
     1280 
     1281  * '''Options:''' yes, no, undecided 
     1282  * '''Default:''' no 
     1283  * '''Preferences:''' yes,undecided,no 
     1284 
     1285Rationale: There is no reason not to do this. If you don't like the style,  
     1286then don't use it, but a standards body should not be in charge of dictating  
     1287good style. 
     1288 
     1289=== #181 Add WHEN and UNLESS to the base module === 
     1290 
     1291  * '''Options:''' yes, no, undecided 
     1292  * '''Default:''' no 
     1293  * '''Preferences:''' yes,undecided,no 
     1294 
     1295Rationale: These are very useful and help to discourage one-armed `if`s. 
     1296 
     1297=== #182 Add WHILE and UNTIL === 
     1298 
     1299These trivial syntaxes add familiarity for new Scheme programmers 
     1300coming from other languages, as will almost always be the case.  LOOP 
     1301is too big and named-LET too alien. 
     1302 
     1303  * '''Options:''' yes, no, undecided 
     1304  * '''Default:''' no 
     1305  * '''Preferences:''' no,undecided,yes 
     1306 
     1307Rationale: They are rarely if ever used among non-beginner Scheme  
     1308programmers, and I know of very few teachers who would encourage its use. 
     1309Thus, they don't provide enough usefulness to the general Scheme community  
     1310to warrant standardization. 
     1311 
     1312=== #183 Escaped newline removes following whitespace? === 
     1313 
     1314Andy Wingo suggests the R6RS handling of escaped embedded newlines: 
     1315 
     1316{{{ 
     1317    "asdadf \ 
     1318    asdfadf" 
     1319}}} 
     1320 
     1321in R6RS has the same meaning as "asdf asdfadf".  It allows you to 
     1322nicely indent strings that you need to line-break for width.  I 
     1323suggest that the production 
     1324 
     1325{{{ 
     1326   \ NEWLINE WHITESPACE* 
     1327}}} 
     1328 
     1329within string literals be elided. 
     1330 
     1331Note an alternate method for handling embedded strings with nice 
     1332indentation is scribble syntax. 
     1333 
     1334We voted on various string syntaxes previously but did not 
     1335specifically propose this R6RS extension.  We should have a rationale 
     1336if we don't follow it. 
     1337 
     1338  * '''Options:''' yes, no, undecided 
     1339  * '''Default:''' no 
     1340  * '''Preferences:''' yes,undecided,no 
     1341 
     1342Rationale: This is really useful, but the scribble syntax is also very useful, and  
     1343we should consider this as a separate ticket. 
     1344 
     1345=== #184 Require CHAR=?, STRING=? etc. to accept arbitrary numbers of arguments? === 
     1346 
     1347R5RS makes a point of specifying that supporting more than two 
     1348arguments is optional.  (Everything not explicitly mentioned is 
     1349optional, so this may have significance.)  R6RS requires accepting 2 
     1350or more arguments.  Currently Racket, Gambit, Guile, Chez, Ikarus, 
     1351Larceny, Ypsilon, Mosh, and Scheme 9 support the feature, whereas 
     1352Gauche, MIT, Chicken, Bigloo, Scheme48/scsh, Kawa, SISC, Chibi, 
     1353STklos, and SSCM don't. 
     1354 
     1355  * '''Options:''' yes, no, undecided 
     1356  * '''Default:''' no 
     1357  * '''Preferences:''' undecided,yes,no 
     1358 
     1359Rationale: I don't understand why we would limit this. It seems like an strange  
     1360limitation to enforce on users. I would like to see more rationale on why we might  
     1361want to vote no, but otherwise I tihnk they should accept multiple numbers of  
     1362arguments. 
     1363 
     1364=== #185 Add sixth "centered" division operator === 
     1365 
     1366From the Guile manual: 
     1367 
     1368* Scheme Procedure: centered/ x y 
     1369* Scheme Procedure: centered-quotient x y 
     1370* Scheme Procedure: centered-remainder x y 
     1371 
     1372These procedures accept two real numbers x and y, where the divisor y 
     1373must be non-zero. centered-quotient returns the integer q and 
     1374centered-remainder returns the real number r such that x = q*y + r and 
     1375-|y/2| <= r < |y/2|. centered/ returns both q and r, and is more 
     1376efficient than computing each separately. 
     1377 
     1378Note that centered-quotient returns x/y rounded to the nearest 
     1379integer. When x/y lies exactly half-way between two integers, the tie 
     1380is broken according to the sign of y. If y > 0, ties are rounded 
     1381toward positive infinity, otherwise they are rounded toward negative 
     1382infinity. This is a consequence of the requirement that -|y/2| <= r < 
     1383|y/2|. 
     1384 
     1385Note that these operators are equivalent to the R6RS operators div0, 
     1386mod0, and div0-and-mod0. 
     1387 
     1388--Andy Wingo 
     1389 
     1390Taylor Campbell thinks these are useless.  We should probably have use 
     1391cases for _any_ division operator we include. 
     1392 
     1393  * '''Options:''' yes, no, undecided 
     1394  * '''Default:''' no 
    7401395  * '''Preferences:''' undecided 
    7411396 
    742 == WG1 - Numerics == 
    743  
    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:''' undecided 
    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. 
    771  
    772   * '''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:''' r6rs,rational,inexact,r5rs,complex,inexact-only,quaternion 
    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,r6rs,r5rs 
    797  
    798 == WG1 - Reader Syntax == 
    799  
    800 === #12 symbol literal extensions === 
    801  
    802 In R5RS, symbols parsed as any sequence of valid symbol characters 
    803 that does not begin with a character that can begin a number.  The 
    804 three exceptions `+`, `-` and `...` are also provided.  This allows 
    805 parsing with only constant lookahead to determine type. 
    806  
    807 R6RS added additional exceptions for symbols beginning with `->`, a 
    808 common idiom, still allowing parsers to determine type with a constant 
    809 lookahead. 
    810  
    811 John Cowan proposes allowing anything that cannot be parsed as a 
    812 number to be a valid symbol.  This removes the special case 
    813 exceptions, but may require arbitrary lookahead. 
    814  
    815 Alex Shinn proposes symbols are any sequence of valid symbol 
    816 characters that does not have a prefix which is a valid number.  This 
    817 removes the special case exceptions, allows constant lookahead, and 
    818 allows extensions to number syntax. 
    819  
    820   * '''Proposals:''' 
    821     * '''r5rs:''' symbols may not begin with `-`, except for `-` itself 
    822     * '''r6rs:''' symbols may not begin with `-[^>]` 
    823     * '''cowan:''' symbols are anything that doesn't parse as a number 
    824     * '''shinn:''' symbols may not begin with a number prefix 
    825   * '''Options:''' r5rs, r6rs, cowan, shinn, undecided 
    826   * '''Default:''' r5rs 
    827   * '''Preferences:''' shinn,r6rs,cowan,r5rs 
    828  
    829 === #84 Need to decide on a list of named character escapes === 
    830  
    831 The WG has voted to have a list of character names. 
    832  
    833 The list in R5RS and the longer list in R6RS are only informative.  I 
    834 suggest adopting the R6RS list and making it normative. 
    835  
    836   * '''Proposals:''' 
    837     * '''r5rs:''' space, newline 
    838     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.6 R6RS Characters] 
    839     * '''shinn:''' space, tab, newline, return, escape, null, alarm, backspace 
    840   * '''Options:''' r5rs, r6rs, shinn 
    841   * '''Default:''' r5rs 
    842   * '''Preferences:''' r6rs,shinn,r5rs 
    843  
    844 === #104 list of mnemonic string escapes === 
    845  
    846 Similar to #84, we need to choose a specific list of mnemonic escapes 
    847 like \n and \t to be recognized in strings. 
    848  
    849   * '''Proposals:''' 
    850     * '''r5rs:''' `\\`, `\"` 
    851     * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.7 R6RS Strings] 
    852     * '''shinn:''' `\\`, `\"`, `\t`, `\n`, `\r`, `\e`, `\a`, `\b` 
    853   * '''Options:''' r5rs, r6rs, shinn 
    854   * '''Default:''' r5rs 
    855   * '''Preferences:''' r6rs,shinn,r5rs 
     1397Rationale: I don't understand these well enough to vote on them yet. 
     1398 
     1399=== #195 Editorial: proposed rewording for `begin` === 
     1400 
     1401The documentation for `begin' specifies that it is a sequential 
     1402construct; but really it splices as well, and also of course it's a 
     1403keyword for the module system currently.  This is inaccurate of the 
     1404spec to say that "begin is for sequencing". 
     1405 
     1406Suggestion: adopt the language of R6RS section 11.4.7. 
     1407 
     1408--Andy Wingo 
     1409 
     1410We should explain somewhere the four kinds of `begin`s: (begin expr 
     1411...), (begin decl ...), top-level begin, and module-top-level begin. 
     1412Note that R7RS like R5RS does not have (begin decl ... expr ...). 
     1413 
     1414Vote `yes` to adopt the R6RS description, modified for differences in 
     1415the language. 
     1416 
     1417  * '''Options:''' yes, no, undecided 
     1418  * '''Default:''' no 
     1419  * '''Preferences:''' yes,undecided,no 
     1420 
     1421Rationale: I think we ought to have a splicing `begin` form, so I don't 
     1422know what else would differ between R6RS and R7RS in this regard. 
     1423 
     1424=== #198 Make it an error for a procedure mapped by MAP and friends to mutate the result list/string/vector === 
     1425 
     1426This is possibly difficult to enforce, and can break existing R5RS 
     1427programs written in very bad style. 
     1428 
     1429  * '''Options:''' yes, no, undecided 
     1430  * '''Default:''' no 
     1431  * '''Preferences:''' yes,undecided,no 
     1432 
     1433Rationale: We don't have to enforce this, but it does let people write  
     1434things in a way that they can get away with being slightly lazy. Making it  
     1435an error is a good thing in this case. 
     1436 
     1437=== #199 Make it an error for a procedure mapped by MAP and friends to return more than once === 
     1438 
     1439This is possibly difficult to enforce, and can break existing R5RS 
     1440programs. 
     1441 
     1442  * '''Options:''' yes, no, undecided 
     1443  * '''Default:''' no 
     1444  * '''Preferences:''' undecided,yes,no 
     1445 
     1446Rationale: I would like to know the ramifications of this. 
     1447 
     1448=== #200 Completing the blob procedures === 
     1449 
     1450Add `blob`, `blob-map`, `blob-for-each`, and blob conversion functions 
     1451to and from lists/vectors/strings. 
     1452 
     1453  * '''Options:''' yes, no, undecided 
     1454  * '''Default:''' no 
     1455  * '''Preferences:''' undecided,yes,no 
     1456 
     1457Ratione: I know that these would be useful, but I don't know what they would  
     1458look like, and they should be in the spirit of blobs and not ad hoc.  
     1459 
     1460=== #205 Roll partial-blob-copy(!) into blob-copy(!) === 
     1461 
     1462... with extra arguments. 
     1463 
     1464  * '''Options:''' yes, no, undecided 
     1465  * '''Default:''' no 
     1466  * '''Preferences:''' yes,undecided,no 
     1467 
     1468Rationale: This simplifies the name space and should make things easier.  
     1469I like this sort of interface better than remembering another name. 
     1470 
     1471=== #206 Provide read-syntax for blobs === 
     1472 
     1473R6RS provides a `#vu8(...)` read-syntax for bytevectors.  SRFI-4 uses 
     1474`#u8(...)`. 
     1475 
     1476  * '''Options:''' r6rs, srfi-4, none, undecided 
     1477  * '''Default:''' none 
     1478  * '''Preferences:''' r6rs,srfi-4,undecided,none 
     1479 
     1480Rationale: We should have one, regardless of what we pick, and I prefer  
     1481the more descriptive (slightly) R6RS version more than the SRFI-4 version. 
     1482 
     1483=== #207 Editorial: Polar complex numbers are inexact === 
     1484 
     1485Add a note saying that `1@2` and `(make-polar 1 2)` MAY evaluate to an 
     1486inexact complex number. 
     1487 
     1488  * '''Options:''' yes, no, undecided 
     1489  * '''Default:''' no 
     1490  * '''Preferences:''' undecided,yes,no 
     1491 
     1492Rationale: I haven't thought enough about this. 
     1493 
     1494=== #208 Is || a valid identifier? === 
     1495 
     1496The grammar in 7.1.1 allows `||` as an <identifier>. However, page 5 
     1497suggests the `|...|` form is only for convenience (e.g. `|foo bar|` is 
     1498equivalent to `foo\x20;bar`). There's no way to normalise `||` to 
     1499anything without the vertical bars that's a valid identifier. Was that 
     1500intentional, or should the rule be 
     1501 
     1502{{{ 
     1503<vertical bar> <symbol element>+ <vertical bar> 
     1504}}} 
     1505 
     1506Vote `remove` to remove the `|...|` syntax altogether. 
     1507 
     1508  * '''Options:''' remove, empty-valid, empty-invalid, undecided 
     1509  * '''Default:''' empty-valid 
     1510  * '''Preferences:''' empty-valid,empty-invalid,undecided,removed 
     1511 
     1512Rationale: There's no reason to limit the bar syntax when || is a perfectly  
     1513good identifier. We should remove language that suggests it is only for convenience. 
     1514 
     1515=== #191 Include CLOSE-PORT ? === 
     1516 
     1517Should we include `close-port`, as a generic version of 
     1518`close-input-port` and `close-output-port`? 
     1519 
     1520  * '''Options:''' yes, no, undecided 
     1521  * '''Default:''' no 
     1522  * '''Preferences:''' yes,no 
     1523 
     1524Rationale: It's useful and general, but I'm not attached to it. 
     1525 
     1526=== #188 Clarify wording of `and` and `or` definitions === 
     1527 
     1528The definitions of `and` and `or` may be slightly confusing. Reword 
     1529them to be more clear. One possible hiccup is that the current 
     1530language permits the return of different false values, while a clearer 
     1531wording may preclude this. 
     1532 
     1533R6RS provides a clearer definition that does not provide wiggle room 
     1534for multiple false values. Should we use that? 
     1535 
     1536  * '''Options:''' yes, no, undecided 
     1537  * '''Default:''' no 
     1538  * '''Preferences:''' yes,undecided,no 
     1539 
     1540Rationale: We should clarify this wording specifically to eliminate this  
     1541ambiguity about false values. 
     1542 
     1543=== #187 Clarify duplicate bindings in `let*` === 
     1544 
     1545The language of the standard could clarify that duplicate bindings are 
     1546permitted in the clauses of a `let*`. 
     1547 
     1548  * '''Options:''' yes, no, undecided 
     1549  * '''Default:''' no 
     1550  * '''Preferences:''' yes,undecided,no 
     1551 
     1552Rationale: Arguably this is not necessary, but it does help people who  
     1553are trying to read the standard. This is an issue that has cropped up  
     1554from time to time so maybe it makes sense to include language about it  
     1555in the standard, even at the expense of a bit of verbosity. 
     1556 
     1557=== #215 initial value argument to make-blob === 
     1558 
     1559`make-blob` should either have an initial value argument, or rationale 
     1560why it is inconsistent with `make-vector` and `make-string`. 
     1561 
     1562Vote `yes` for an initial value argument. 
     1563 
     1564  * '''Options:''' yes, no, undecided 
     1565  * '''Default:''' no 
     1566  * '''Preferences:''' yes,undecided,no 
     1567 
     1568Rationale: I assume that this will be an optional argument, so, yes. 
     1569 
     1570=== #216 Controlling use of reader labels on output === 
     1571 
     1572There are cases when one does not want to output reader labels for 
     1573shared structure, such as when you don't care (and want the output to 
     1574be more legible), or when you know that the time or space requirements 
     1575to construct the table will be too large. 
     1576 
     1577We could offer a parameter to control this, or have a separate 
     1578procedure (e.g. `write/simple`) which doesn't use the reader labels. 
     1579 
     1580Finer grained control may also let use specify a predicate for which 
     1581values are interesting (e.g. never use labels for strings), or only 
     1582use labels for cycles, etc. 
     1583 
     1584  * '''Options:''' parameter, write/simple, none, undecided 
     1585  * '''Default:''' none 
     1586  * '''Preferences:''' undecided,none,parameter,write/simple 
     1587 
     1588Rationale: Is this is common use? What would this look like? I want more discussion on  
     1589this, but otherwise, I am not sure it makes sense, so I'm going with none after  
     1590undecided.