Changes between Version 5 and Version 6 of WG1BallotHsu

06/29/11 01:27:20 (6 years ago)

Third Ballot


  • 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.  
    14 = WG1 Ballot Items To Finalize By Jan. 9 = 
    16 == WG1 - Core == 
     14= WG1 Ballot Items To Finalize by July 1st = 
     16= Previous Undecided and Re-opened Ballot Items = 
    1818=== #32 user-defined types === 
    2121as in SRFI-9, SRFI-99 or the R6RS record system? 
     23WG1 voted '''srfi-9''' before.  New arguments against filter 
     24constructors were raised, so the ticket was re-opened. 
     27  * 
    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 
    33 === #50 byte-vectors === 
    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. 
    40 Do we provide a syntax and basic API for these in WG1? 
    42   * '''Proposals:''' 
    43     * '''r6rs:''' [ 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 
    50 R6RS has a clumsy interface that is corrected, IMO, by Cowan's proposal. 
    52 === #55 Lazy evaluation === 
    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. 
    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. 
    68   * '''Options:''' r5rs, srfi-45, none, wg2, undecided 
    69   * '''Default:''' r5rs 
    70   * '''Preferences:''' undecided,r5rs,srfi-45,wg2,none 
    72 === #57 Random Numbers === 
    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? 
    79   * '''Proposals:''' 
    80     * '''srfi-27:''' [ 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 
    88 I tend to think that CL is okay here, but absent that choice, a simpler approach that is flexible is preferable.  
    90 === #62 Environment Variables === 
    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. 
    99 We have `command-line` and `exit` from ModulesShinn, so the question 
    100 remains if we should add SRFI-98 environment accessors. 
    102   * '''Options:''' srfi-98, none, wg2, undecided 
    103   * '''Default:''' none 
    104   * '''Preferences:''' srfi-98 
    106 === #68 "Undefined value" vs. "undefined values" === 
    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? 
    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. 
    117   * '''Options:''' r5rs, r6rs, zero, undecided 
    118   * '''Default:''' r5rs 
    119   * '''Preferences:''' r6rs,r5rs 
    121 === #49 Undefined value API === 
    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. 
    133 Vote `generate` for a `(void)` procedure, `test` for `undefined?`, and 
    134 `both` for both. 
    136   * '''Options:''' generate, test, both, none, wg2, undecided 
    137   * '''Default:''' none 
    138   * '''Preferences:''' generate 
    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. 
    142 === #51 support for cyclic structures in primitives === 
    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 [ 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. 
    152 Do we want to specify the behavior when these primitives encounter 
    153 cyclic data? 
    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. 
    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 
    167 === #69 Dynamic Parameters === 
    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. 
    173 Instead of special variables, SRFI-39 provides first-class "parameter" 
    174 objects with dynamic bindings.  Do we want to provide something 
    175 similar? 
    177   * '''Proposals:''' 
    178     * '''srfi-39:''' [ 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 
    185 === #70 accessing the system time === 
    187 Short of a full time and date library, a single procedure 
    189   (current-seconds) 
    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). 
    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. 
    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 
    211 === #109 elapsed time === 
    213 Should we have functions allowing a program to compute elapsed time, 
    214 as distinct from calendar time? 
    216 TimeCowan contains a proposal. 
    218   * '''Options:''' cowan, yes, no, wg2, undecided 
    219   * '''Default:''' no 
    220   * '''Preferences:''' cowan,yes 
    222 === #78 Should we have case-lambda? === 
    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. 
    229   * '''Options:''' yes, no, module, wg2, undecided 
    230   * '''Default:''' no 
    231   * '''Preferences:''' yes,module 
    233 === #82 missing port? procedure === 
    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. 
    241 Shall we require it? 
    243   * '''Options:''' yes, no, module, wg2, undecided 
    244   * '''Default:''' no 
    245   * '''Preferences:''' yes,module 
    247 === #107 port status detection === 
    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? 
    253   * '''Options:''' port-open?, port-closed?, both, no, wg2, undecided 
    254   * '''Default:''' no 
    255   * '''Preferences:''' port-closed?,port-open?,both 
    257 === #87 Allow multiple producers in `call-with-values` === 
    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. 
    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`. 
    268 Do we add this extension? 
    270   * '''Options:''' yes, no, wg2, undecided 
    271   * '''Default:''' no 
    272   * '''Preferences:''' yes 
    274 === #88 SRFI 87: => in CASE === 
    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. 
    280 Do we add this extension? 
    282   * '''Options:''' yes, no, wg2, undecided 
    283   * '''Default:''' no 
    284   * '''Preferences:''' yes 
    286 === #89 SRFI 61: COND => with generator and guard === 
    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. 
    294 Do we add this extension? 
    296   * '''Options:''' yes, no, wg2, undecided 
    297   * '''Default:''' no 
    298   * '''Preferences:''' yes 
    300 This is a good step towards unifying the syntaxes of various dispatch mechanisms, such as syntax-case, match, and cond. 
    302 === #90 Multiple values in COND => clauses === 
    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. 
    311   * '''Options:''' yes, no, wg2, undecided 
    312   * '''Default:''' no 
    313   * '''Preferences:''' yes 
    315 === #91 INCLUDE at the REPL === 
    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. 
    321   * '''Options:''' yes, no, wg2, undecided 
    322   * '''Default:''' no 
    323   * '''Preferences:''' yes 
    325 === #92 Case-folding flags === 
    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. 
    334 Note PortsCowan provides a separate means of controlling 
    335 case-sensitivity per-port. 
    337 Vote `per-datum` for the next-datum-only #ci/#cs syntax. 
    339   * '''Options:''' r6rs, per-datum, none, wg2, undecided 
    340   * '''Default:''' none 
    341   * '''Preferences:''' r6rs 
    343 === #116 Source File Character Encoding === 
    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? 
    351   * '''Options:''' utf-8, emacs, unspecified, undecided 
    352   * '''Default:''' none 
    353   * '''Preferences:''' unspecified 
    355 === #93 Removing string mutability === 
    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. 
    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. 
    365   * '''Options:''' yes, no, module, undecided 
    366   * '''Default:''' no 
    367   * '''Preferences:''' no 
    369 === #83 Auxiliary Keywords === 
    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? 
    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. 
    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. 
    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. 
    387   * '''Options:''' bound, unbound, unhygienic, undecided 
    388   * '''Preferences:''' bound 
    390 === #101 exactness and `eqv?`/`equal?` === 
    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 
    396    {{{(equal? 0 0.0) => #f}}} 
    398 whereas 
    400    {{{(= 0 0.0) => #t}}} 
    402 Some users consider this confusing, others sometimes want an `equal?` 
    403 that behaves like `=` for numbers. 
    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. 
    411   * '''Options:''' yes, equal=?, inexact-equal?, no, wg2, undecided 
    412   * '''Default:''' no 
    413   * '''Preferences:''' no,equal=?,inexact-equal? 
    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. 
    417 === #102 module syntax name === 
    419 A bikeshed color issue, we need to choose the 
    420 actual names for the module syntax for the winner 
    421 of #2. 
    423 `import`, `export` and `include` are fairly universal 
    424 and no alternate is suggested unless someone wants 
    425 to write in a proposal. 
    427 The enclosing syntax can be called either 
    428 `library` as in R6RS, `module` or some other proposal. 
    430   * '''Options:''' library, module, undecided 
    431   * '''Default:''' library 
    432   * '''Preferences:''' library 
    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. 
    436 === #103 module body syntax name === 
    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. 
    443   * '''Options:''' body, begin, scheme, code, undecided 
    444   * '''Default:''' body 
    445   * '''Preferences:''' begin,code,body,scheme 
    447 === #105 case-insensitive module includes === 
    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. 
    456   * '''Options:''' yes, no, wg2, undecided 
    457   * '''Default:''' no 
    458   * '''Preferences:''' yes 
    460 This can be implemented with a reader parameter and unhygienic macros, but absent those, this makes sense, and it is generally useful. 
    462 === #106 conditional code selection === 
    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 [ SRFI-0] provides 
    468 `cond-expand`, [ SRFI-103] 
    469 provides a library naming extension, and numerous other personal hacks exist. 
    471 Do we want to include something along these lines in WG1 Scheme? 
    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 
    481 None of these are good enough to put in a Small Scheme. Let WG2 have it. 
    483 === #108 immutable data interface === 
    485 R5RS specifies literal data in source code as immutable, but otherwise 
    486 provides no way to generate or introspect immutable data. 
    488 One proposal is given in ImmutableData, providing `mutable?`, 
    489 `make-immutable` and `immutable->mutable`. 
    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. 
    496   * '''Proposals:''' 
    497     * '''medernach:''' ImmutableData 
    498     * '''racket:''' `shared`, `immutable?` ([]) 
    499   * '''Options:''' medernach, racket, no, undecided 
    500   * '''Default:''' no 
    501   * '''Preferences:''' undecided 
    503 I think this needs more discussion and proofs. 
    505 === #111 require `equal?` to return `#t` if `eqv?` does === 
    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. 
    513   * '''Options:''' yes, no, undecided 
    514   * '''Default:''' no 
    515   * '''Preferences:''' yes 
    517 == WG1 - Exceptions == 
    519 === #18 exception system === 
    521 R6RS provided a detailed exception system with support for raising and 
    522 catching exceptions, using a hierarchy of exception types. 
    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. 
    527   * '''Proposals:''' 
    528     * '''r6rs:''' [ 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 
    534 Better to go with R6RS than yet another system. Either that, or let WG2 have it. 
    536 === #19 when to throw an error === 
    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. 
    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. 
    547 R5RS specifies only 3 situations where an error is required to be 
    548 signalled, leaving most situations unspecified as described in 
    549 ErrorSituations. 
    551   * '''Options:''' r5rs, r6rs, undecided 
    552   * '''Default:''' r5rs 
    553   * '''Preferences:''' undecided 
    555 == WG1 - I/O == 
     37  * '''Default:''' srfi-9 
     38  * '''Preferences:''' hsu,gleckler,wg2,none,srfi-9 
     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. 
    55742=== #28 binary I/O ports === 
    56146be mixed on the different port types? 
    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. 
    56650R6RS provides an entirely new I/O system, as well as a separate 
    57559aspects will be merged as needed. 
     61WG1 voted weakly in favor of PortsCowan before. 
    57763  * '''Proposals:'''  
    57864    * '''r6rs:''' [ R6RS Port I/O] 
    57965    * '''r6rs-simple:''' [ R6RS Simple I/O] 
    58066    * '''srfi-91:''' [ 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 
    586 I have not had enough time to read over the history of these things, and I need more time. 
    588 === #29 port encodings === 
    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? 
    594   * '''Proposals:'''  
    595     * '''r6rs:''' [ R6RS Port I/O] 
    596     * '''srfi-91:''' [ 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. 
     75=== #83 Auxiliary Keywords === 
     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? 
     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 
     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. 
     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. 
     93WG1 voted '''unbound''' previously.  New issues were brought up on the 
     94list so the ticket was re-opened. 
     97  * [wiki:Keywords] 
     98  * 
     100  * '''Options:''' bound, unbound, unhygienic, undecided 
     101  * '''Default:''' unbound 
     102  * '''Preferences:''' bound 
     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. 
     110=== #3 module naming convention === 
     112We need a naming convention for the core modules and standard 
     113libraries of the new module system. 
     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. 
     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 
     132Rationale: I have not had enough time to look this over. 
     134= New Ballot Items = 
     136== WG1 - Core == 
     138=== #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? === 
     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). 
     144  * '''Options:''' blob, bytevector, byte-vector, u8vector, octet-vector, undecided 
     145  * '''Default:''' blob 
     146  * '''Preferences:''' bytevector,u8vector,octet-vector,byte-vector,blob 
     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. 
     156=== #118 Simple literals must be explicitly delimited. === 
     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. 
     164  * 
     165  * 
     167  * '''Options:''' delimited, unspecified, undecided 
     168  * '''Default:''' unspecified 
     169  * '''Preferences:''' delimited,unspecified 
     171Rationale: I prefer to create less ambiguity here. 
     173=== #119 Whether to treat # as a delimiter. === 
     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. 
     179  * '''Options:'''  delimiter, no, undecided 
     180  * '''Default:''' no 
     181  * '''Preferences:''' delimiter 
     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. 
     187=== #123 Extend unquote and unquote-splicing to multiple arguments === 
     189This is a change also made by R6RS (and CL). 
     192  * 
     193  * 
     194  * 
     196  * '''Options:''' multiple, single, undecided 
     197  * '''Default:''' single 
     198  * '''Preferences:''' multiple 
     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.  
     203=== #124 Nested quasiquote semantics === 
     206  * 
     207  * 
     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 
     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. 
     222=== #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) === 
     224This is a change also made by R6RS, specifically: 
     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 
     230  * '''Options:''' r6rs, r5rs, undecided 
     231  * '''Default:''' r5rs 
     232  * '''Preferences:''' r6rs 
     234Rationale: This gives more flexibility to the implementation when dealing with quasiquote. 
     236=== #126 Partly specify the mutability of the values of quasiquote structures === 
     238This is a change also made by R6RS. 
     240  * '''Options:''' r6rs, r5rs, undecided 
     241  * '''Default:''' r5rs 
     242  * '''Preferences:''' r6rs 
     244Rationale: R6RS is an improvement in this regard.  
     246=== #127 Specify the dynamic environment of the ''before'' and ''after'' procedures of dynamic-wind === 
     248R5RS is slightly ambiguous, saying 
     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. 
     254without saying clearly whether ''before'' and ''after'' themselves are 
     255called before or after the dynamic extent is entered or exited. 
     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 
     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. 
     269=== #135 let-values and let*-values === 
     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. 
     275  * '''Options:''' yes, no, module, wg2, undecided 
     276  * '''Default:''' no 
     277  * '''Preferences:''' yes,wg2,module 
     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. 
     283=== #137 Current-seconds semantics still open === 
     285In issue #70, WG1 voted to make `current-seconds` an optional 
     286procedure, but there is no guidance about what it returns. 
     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. 
     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. 
     302TimeCowan is equivalent to the `posix-integer` option, and in addition 
     303changes the name to `current-posix-second`. 
     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 
     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. 
     319=== #147 Allow literal file spec lists in include and include-ci === 
     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. 
     326  * '''Options:''' yes, no, undecided 
     327  * '''Default:''' no 
     328  * '''Preferences:''' undecided,no,yes 
     330Rationale: We should not prohibit extensions to `include`, but we should only  
     331define string based names. 
     333=== #148 Allow include-ci at top level === 
     335Currently `include-ci` is allowed as a module declaration but not at top level, 
     336as `include` is. 
     338  * '''Options:''' yes, no, undecided 
     339  * '''Default:''' no 
     340  * '''Preferences:''' yes 
     342Rationale: This is an oversight. 
     344=== #149 blob ports === 
     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. 
     352  * '''Options:''' cowan, none, undecided 
    599353  * '''Default:''' none 
     354  * '''Preferences:''' cowan 
     356Rationale: We want a way to get a port abstraction on blobs. 
     358=== #150 cond-expand at top level === 
     360Currently `cond-expand` is only valid as a module declaration.  Should 
     361we allow it at top level in a program? 
     363  * '''Options:''' yes, no, undecided 
     364  * '''Default:''' no 
     365  * '''Preferences:''' no 
     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.  
     373=== #153 Renaming blob procedures === 
     375The blob procedures don't follow the same system as the rest.  I 
     376propose these changes: 
     379copy-blob => blob-copy 
     380copy-blob! => blob-copy! 
     381partial-blob => blob-copy-partial 
     382copy-partial-blob! -> blob-copy-partial! 
     385Note this is modulo the choice of "blob" or "bytevector" 
     386or whichever. 
     388  * '''Options:''' new, original, remove, undecided 
     389  * '''Default:''' original 
     390  * '''Preferences:''' new,original 
     392Rationale: Consistent naming is important here, and the hierarchical naming 
     393policy makes much more sense. 
     395=== #154 Physical newline in a string equivalent to \n (that is, U+000A) === 
     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. 
     403  * '''Options:''' unix, local, error, unspecified, undecided 
     404  * '''Default:''' unspecified 
     405  * '''Preferences:''' unix,unspecified 
     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. 
     415=== #155 Make recursively defined code an explicit error === 
     417Allowing examples like these will make code-walkers (including 
     418compilers and interpreters) excessively complicated: 
     420#1=(begin (display #\x) . #1#) 
     422(lambda #2=(a b c #2#) ...) 
     424(+ . #3=(1 2 3 . #3#)) 
     426  * '''Options:''' error, unspecified, undecided 
     427  * '''Default:''' unspecified 
     428  * '''Preferences:''' unspecified 
     430Rationale: Making this an error makes things more complicated, not  
     431less, and it makes life more difficult on naive implementations. Leave 
     432this unspecified. 
     434=== #156 Replace "an error is signalled" with "an implementation-dependent object is raised as if by `raise`" === 
     436The following situations are described in draft 1 (and R5RS) with "an 
     437error is signalled": 
     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. 
     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. 
     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. 
     453  * '''Options:''' signal, unspecified, undecided 
     454  * '''Default:''' unspecified 
     455  * '''Preferences:''' signal 
     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. 
     462=== #162 Remove DELAY and FORCE altogether === 
     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.) 
     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. 
     474  * '''Options:''' remove, keep, lazy, undecided 
     475  * '''Default:''' keep 
    600476  * '''Preferences:''' undecided 
    602 I need more time for this one. 
    604 === #31 custom ports === 
    606 Do we provide a mechanism for custom ports, on which for instance 
    607 string ports could be created? 
    609 R6RS as well as a number of Scheme implementations provide custom 
    610 ports with various APIs. 
    612   * '''Proposals:'''  
    613     * '''r6rs:''' [ R6RS Port I/O] 
    614   * '''Options:''' r6rs, none 
     478Rationale: I think this warrants more work before a final vote. 
     480=== #164 Meaning of char-numeric? === 
     482The current draft, like R6RS, defines `char-numeric?` according to the 
     483nonexistent Unicode Numeric property.  That has to be fixed.  Options: 
     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. 
     489 2. (Omitted, because it does not preserve IEEE Scheme) 
     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. 
     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. 
     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. 
     508  * '''Options:''' any, number, digit, ascii, undecided 
     509  * '''Default:''' ascii 
     510  * '''Preferences:''' number,digit,ascii,any 
     512Rationale: Number seems like the better and more general choice. 
     514=== #166 Add predicate and accessors for error objects === 
     516(Email from Vincent Manis) 
     518Problem: It's impossible to write a portable error handler that writes 
     519out the ''message'' and ''irritants'' that were passed to `error`. 
     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. 
     529Suggestion: Add the following procedures: 
     531`(error-object? `''object''`)` 
     533Returns `#t` if ''object'' is something created by `error`, `#f` 
     534otherwise. Any constraints on type disjointness are up to the 
     537`(error-object-message `''object''`)` 
     539Returns the message of ''object''. 
     541`(error-object-irritants `''object''`)` 
     543Returns a list of the irritants of ''object''. 
     545  * '''Options:''' manis, none, undecided 
     546  * '''Default:''' none 
     547  * '''Preferences:'''  
     549=== #167 Add constructor for error objects === 
     551(Email from Vincent Manis) 
     553Problem: Raising arbitrary objects as exceptions has been found to be 
     554nasty in some other languages (Python and C++ in particular). 
     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: 
     563`(make-error-object `''message''` `''obj'' ...`)` 
     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: 
     574 (define (error message . objs) 
     575   (raise (apply make-error-object message objs))) 
     579  * '''Options:''' manis, none, undecided 
     580  * '''Default:''' none 
     581  * '''Preferences:'''  
     583=== #169 Add standard-*-port procedures === 
     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. 
     589  * '''Options:''' r6rs, none, undecided 
    615590  * '''Default:''' none 
    616591  * '''Preferences:''' r6rs 
    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. 
    620 == WG1 - Libraries == 
    622 === #36 hash-tables === 
    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? 
    628   * '''Options:''' r6rs, srfi-69, no, wg2, undecided 
    629   * '''Default:''' no 
     593Rationale: These are very common and should be provided. 
     595=== #171 Duplicate identifiers in define-record-type === 
     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 
     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. 
     608  * '''Options:''' error, unspecified, undecided 
     609  * '''Default:''' unspecified 
     610  * '''Preferences:''' error 
     612Rationale: This situation doesn't make sense, so it should be an error. 
     614=== #173 Unifying BEGINs === 
     616In R5RS, there are three kinds of BEGINs: 
     6181) All subforms are expressions; this can be used wherever an 
     619expression can be used.  (4.2.3) 
     6212) All subforms are definitions; this can be used wherever an internal 
     622definition can be used.  (5.2.2) 
     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) 
     628In particular, 
     631(define (x) 
     632 (define y 32) 
     633 (begin 
     634   (define z 45) 
     635   (set! y z)) 
     636 y) 
     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. 
     645  * '''Options:''' cowan, r5rs, undecided 
     646  * '''Default:''' r5rs 
     647  * '''Preferences:''' cowan 
     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. 
     653=== #174 Safe uses of multiple values === 
     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 
     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 
     665The definition of `begin` would need to change too: 
     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 ...)))))) 
     679  * '''Options:''' safe-values, r5rs, undecided 
     680  * '''Default:''' r5rs 
     681  * '''Preferences:''' safe-values 
     683Rationale: Most everyone does this, it is pretty much a de facto  
     684standard and we should respect it. 
     686=== #45 Record-let syntax and semantics === 
     689(record-let <record-data> ((<variable> <field>) ...) 
     690  <body>) 
     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>. 
     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. 
     703Do we need to be able to check at runtime if a given record data has 
     704a given field ? 
     707  * '''Options:''' record-let, none, undecided 
     708  * '''Default:''' none 
     709  * '''Preferences:''' record-let,undecided 
     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. 
     714=== #172 Multiple returns from `map` === 
     716R6RS specifies that `map` does not mutate previous results if there 
     717are multiple returns from map. Should we include this language? 
     719  * '''Options:''' r6rs, unspecified, undecided 
     720  * '''Default:''' unspecified 
    630721  * '''Preferences:''' r6rs 
    632 === #113 directory contents === 
    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. 
     726=== #178 Shadowing with internal definitions === 
     728From Andre Von Tonder: 
     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. 
     734In R6RS a more general criterion was used - please see R6RS for 
     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. 
     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))) 
     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: 
     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) 
     771OTOH, it is unclear to me if WG1 allows this or not. 
     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))) 
     784  * '''Options:''' r6rs, r5rs, tonder, undecided 
     785  * '''Default:''' r5rs 
     786  * '''Preferences:''' r6rs,undecided 
     788Rationale: I prefer the R6RS language here, as it scales well and is unambiguous. 
     790== WG1 - Modules == 
     792=== #112 REPL redefinitions === 
     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? 
     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: 
     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 
     808So all 64 combinations for these 4 values in the following 4x4 matrix 
     809are feasible: 
     811|| From/To       || import || import syntax || define || define-syntax || 
     812|| import        ||   ?    ||       ?       ||   ?    ||       ?       || 
     813|| import syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     814|| define        ||   ?    ||       ?       ||   ?    ||       ?       || 
     815|| define-syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     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. 
    639823  * '''Proposals:''' 
    640     *  '''cowan:''' DirectoryPortsCowan 
    641     *  '''directory-files:''' return a list of all files in the dir 
    642     *  '''directory-streams:''' [ 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 
     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. 
     837=== #132 Imports override previous imports? === 
     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? 
     843This ticket refers only to modules - the top-level semantics are 
     844decided in ticket #112. 
     846  * '''Options:''' override, preserve, error, unspecified, undecided 
     847  * '''Default:''' error 
     848  * '''Preferences:''' error,undecided 
     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. 
     854=== #160 Interleaving of imports and code in a module === 
     859   (module (name) 
     860     (begin c1 ...) 
     861     (import (A)) 
     862     (begin c2 ...) 
     863     (import (B)) 
     864     (begin c3 ...)) 
     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. 
     872  * '''Options:''' shinn, interleave, unspecified, undecided 
     873  * '''Default:''' shinn 
     874  * '''Preferences:''' shinn,undecided,interleave 
     876Rationale: Interleaving complicates the semantics. We should keep  
     877with imports as being at the top level. 
     879=== #163 Allow modules at the REPL? === 
     881Should users be allowed to enter a `module` form at the REPL? 
     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. 
     887  * '''Options:''' yes, no, unspecified, undecided 
     888  * '''Default:''' no 
     889  * '''Preferences:''' yes,undecided,unspecified,no 
     891Rationale: This is something that is very convenient to do, and can be  
     892implemented even on implementations that leave the module binding open. 
     894=== #141 What are the semantics of modules with respect to separate compilation? === 
     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. 
     900  * '''Options:''' compile-time, unspecified, undecided 
     901  * '''Default:''' undecided 
    645902  * '''Preferences:''' undecided 
    647 == WG1 - Macros == 
    649 === #48 let-syntax === 
    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. 
    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. 
    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. 
    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. 
     908=== #158 mutating imports === 
     910Currently the semantics of calling set! or define 
     911on an imported binding is undefined.  Do we 
     912want to specifically make this an error? 
     914  * '''Options:''' error, allowed, unspecified, undecided 
     915  * '''Default:''' unspecified 
     916  * '''Preferences:''' error,undecided,unspecified 
     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. 
     922=== #159 base environments === 
     924What is the base environment provided by the repl, 
     925scripts, and the result of (scheme-report-environment 7)? 
     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. 
     932  * '''Options:''' shinn, undecided 
     933    * '''shinn:''' intention as described above 
     934  * '''Default:''' shinn 
     935  * '''Preferences:''' undecided,shinn 
     937Rationale: We should have more discussion on this. 
     939=== #161 module argument to eval === 
     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. 
     945R6RS provides a procedure `environment` which just 
     946takes a list that looks like an import spec an generates 
     947the corresponding environment. 
     949  * '''Options:''' r6rs, none, undecided 
     950  * '''Default:''' r6rs 
     951  * '''Preferences:''' r6rs,undecided,none 
     953Rationale: R6RS' `environment` is extremely useful and works well. 
     955=== #139 `exit` === 
     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. 
     961  * '''Options:''' yes, no, undecided 
     962  * '''Default:''' yes 
     963  * '''Preferences:''' yes,undecided,no 
     965Rationale: Very useful, yes. 
     967=== #144 strip prefix on import === 
     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. 
     975Specific proposal: `(strip-prefix <import-set> <prefix-identifier>)`. 
     977  * '''Options:''' yes, no, undecided 
     978  * '''Default:''' no 
     979  * '''Preferences:''' yes,undecided,no 
     981Rationale: This is very useful, and a common form among implementation 
     982module systems. 
     984== WG1 - I/O == 
     986=== #133 Provide read-line === 
     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. 
     993  * '''Options:''' yes, no, undecided 
     994  * '''Default:''' no 
     995  * '''Preferences:''' yes,undecided,no 
     997Rationale: very common and very useful. 
     999=== #170 Add with-error-to-file procedure === 
     1001Since we now have `current-error-port`, arguably we should have 
     1002`with-error-to-file` for completeness. 
     1004  * '''Options:''' yes, no, undecided 
     1005  * '''Default:''' no 
     1006  * '''Preferences:''' yes,undecided,no 
     1008Rationale: Useful, and it rounds things out. 
     1010=== #176 Are string ports exclusively character ports? === 
     1012From scheme-reports discussion list, by John Cowan: 
     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. 
     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. 
     1024  * '''Options:''' character-only, unspecified, undecided 
     1025  * '''Default:''' unspecified 
     1026  * '''Preferences:''' character-only,undecided,unspecified 
     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. 
     1032=== #177 Distinguish file and string ports? === 
     1034Should there exist predicates that identify string and file ports? 
     1036  * '''Options:''' string-port?, file-port?, both, neither, undecided 
     1037  * '''Default:''' neither 
     1038  * '''Preferences:''' both,neither,string-port?,file-port?,undecided 
     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.  
     1043=== #131 Output procedures return value === 
     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? 
     1049Need proposals. 
     1051  * '''Options:''' r5rs, undecided 
     1052  * '''Default:'''  
     1053  * '''Preferences:''' r5rs,undecided 
     1055Rationale: We should stick with the unspecified error, there is no good reason  
     1056to change this. 
     1058=== #134 Provide flush-output-port === 
     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. 
     1064  * '''Options:''' yes, no, undecided 
     1065  * '''Default:''' no 
     1066  * '''Preferences:''' yes,undecided,no 
     1068Rationale: This is an extremely useful procedure and is crucial in some  
     1071== WG1 - Numerics == 
     1073=== #117 Real numbers have imaginary part #e0 === 
     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. 
     1079  * '''Options:''' exact-only, any-zero, unspecified, undecided 
     1080  * '''Default:''' any-zero 
     1081  * '''Preferences:''' exact-only,any-zero,unspecified,undecided 
     1083Rationale: I prefer the exact form. 
     1085=== #120 Define the semantics of the transcendental functions more fully === 
     1087R6RS has an extended description of the transcendental functions.  Do 
     1088we want to include this? 
     1090TODO: explain the exact diff, why it is desirable, and whether any 
     1091reasonable alternatives are possible. 
     1094  * 
     1096  * '''Options:''' r6rs, r5rs, undecided 
     1097  * '''Default:''' r5rs 
     1098  * '''Preferences:''' r6rs,undecided,r5rs 
     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. 
     1103=== #121 The semantics of expt for zero bases has been refined === 
     1105This is a change also made by R6RS. 
     1107R5RS says: 
     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. 
     1111R6RS says: 
     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. 
     1116  * '''Options:''' r6rs, r5rs, undecided 
     1117  * '''Default:''' r5rs 
     1118  * '''Preferences:''' r6rs,undecided,r5rs 
     1120Rationale: I prefer the more detailed description. 
     1122=== #122 Make infinity, NaN, and -0.0 semantics (when supported) consistent with IEEE 754 === 
     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. 
     1128R6RS both requires these values and requires they be consistent with 
     1129IEEE 754. 
     1131  * '''Options:''' ieee-754, unspecified, undecided 
     1132  * '''Default:''' unspecified 
     1133  * '''Preferences:''' ieee-754,undecided,unspecified 
     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. 
     1139=== #175 Control of significant digits or decimal places in NUMBER->STRING === 
     1141Vincent Manis pleads for a way to write numbers with a specified precision: 
     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 
     1153  * '''Options:''' manis, none, undecided 
     1154  * '''Default:''' none 
     1155  * '''Preferences:''' none,undecided,manis 
     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. 
     1161=== #138 DivisionRiastradh domain === 
     1163Zero as a divisor aside, what should the domain of the proposed 
     1164procedures be? 
     1166 1. Any real numbers? 
     1167 1. Integers only? 
     1168 1. Exact integers only? 
     1170  * '''Options:''' reals, integers, exact-integers 
     1171  * '''Default:'''  
     1172  * '''Preferences:''' undecided 
     1174Rationale: I want to see more discussion on this. 
     1176=== #217 DivisionRiastradh exactness preservation === 
     1178What about exactness preservation? 
     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 
     1184  * '''Options:''' not-exactness-preserving, exactness-preserving, exactness-preserving-unless 
     1185  * '''Default:'''  
     1186  * '''Preferences:''' undecided 
     1188Rationale: I want to see more discussion on this before I make my decision. 
     1190=== #140 Removing `quotient`, `remainder`, `modulo` === 
     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: 
     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. 
     1202Here's what DivisionRiastradh says: 
     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. 
     1211> [...] 
     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. 
     1219On the other hand, we may prefer relegating them to a 
     1220backward-compatibility module. 
     1222Vote "yes" to keep, "no" to remove, and "module" to relegate to a 
     1225  * '''Options:''' yes, no, module, undecided 
     1226  * '''Default:''' yes 
     1227  * '''Preferences:''' module,yes,undecided,no 
     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. 
     1233=== #151 Extend `finite?` and `nan?` to non-real values === 
     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`. 
    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 
    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. 
    685 === #97 syntax-rules special literals === 
    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. 
    691 However their behavior when used in the literals list of 
    692 syntax-rules is ambiguous, and simply breaks in most implementations. 
    694 Rather than breaking, it makes sense to go ahead and treat 
    695 them as normal literals, overriding their special meanings. 
    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. 
    701   * '''Options:''' literal, error, unspecified, undecided 
    702   * '''Default:''' unspecified 
    703   * '''Preferences:''' literal,error 
    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. 
    707 == WG1 - Modules == 
    709 === #3 module naming convention === 
    711 We need a naming convention for the core modules and standard 
    712 libraries of the new module system. 
    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. 
    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. 
    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. 
    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. 
    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 
     1247Rationale: I don't know the ramifications of this, and I would like more  
     1248discussion on this. 
     1250=== #152 exact-integer-sqrt inconsistent with multiple values module === 
     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. 
     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. 
     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 
     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. 
     1272=== #180 Make case and cond clauses into bodies === 
     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. 
     1278The counter-argument is that it doesn't "look" like the sort of place 
     1279definitions are allowed. 
     1281  * '''Options:''' yes, no, undecided 
     1282  * '''Default:''' no 
     1283  * '''Preferences:''' yes,undecided,no 
     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. 
     1289=== #181 Add WHEN and UNLESS to the base module === 
     1291  * '''Options:''' yes, no, undecided 
     1292  * '''Default:''' no 
     1293  * '''Preferences:''' yes,undecided,no 
     1295Rationale: These are very useful and help to discourage one-armed `if`s. 
     1297=== #182 Add WHILE and UNTIL === 
     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. 
     1303  * '''Options:''' yes, no, undecided 
     1304  * '''Default:''' no 
     1305  * '''Preferences:''' no,undecided,yes 
     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. 
     1312=== #183 Escaped newline removes following whitespace? === 
     1314Andy Wingo suggests the R6RS handling of escaped embedded newlines: 
     1317    "asdadf \ 
     1318    asdfadf" 
     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 
     1326   \ NEWLINE WHITESPACE* 
     1329within string literals be elided. 
     1331Note an alternate method for handling embedded strings with nice 
     1332indentation is scribble syntax. 
     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. 
     1338  * '''Options:''' yes, no, undecided 
     1339  * '''Default:''' no 
     1340  * '''Preferences:''' yes,undecided,no 
     1342Rationale: This is really useful, but the scribble syntax is also very useful, and  
     1343we should consider this as a separate ticket. 
     1345=== #184 Require CHAR=?, STRING=? etc. to accept arbitrary numbers of arguments? === 
     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. 
     1355  * '''Options:''' yes, no, undecided 
     1356  * '''Default:''' no 
     1357  * '''Preferences:''' undecided,yes,no 
     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  
     1364=== #185 Add sixth "centered" division operator === 
     1366From the Guile manual: 
     1368* Scheme Procedure: centered/ x y 
     1369* Scheme Procedure: centered-quotient x y 
     1370* Scheme Procedure: centered-remainder x y 
     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. 
     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 < 
     1385Note that these operators are equivalent to the R6RS operators div0, 
     1386mod0, and div0-and-mod0. 
     1388--Andy Wingo 
     1390Taylor Campbell thinks these are useless.  We should probably have use 
     1391cases for _any_ division operator we include. 
     1393  * '''Options:''' yes, no, undecided 
     1394  * '''Default:''' no 
    7401395  * '''Preferences:''' undecided 
    742 == WG1 - Numerics == 
    744 === #79 rational-expt === 
    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? 
    751   * '''Options:''' yes, no, module, wg2, undecided 
    752   * '''Default:''' no 
    753   * '''Preferences:''' undecided 
    755 === #81 What numeric tower variants should be supported? === 
    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. 
    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. 
    767 Note quaternions are a fairly rare numeric type, known to be provided 
    768 only by extensions to [ scm] 
    769 and [ chicken], and thus 
    770 may be difficult for other implementations to support if required. 
    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 
    784 === #100 integral division === 
    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. 
    792   * '''Proposals:''' 
    793     * '''riastradh:''' DivisionRiastradh 
    794   * '''Options:''' r5rs, r6rs, riastradh, undecided 
    795   * '''Default:''' r5rs 
    796   * '''Preferences:''' riastradh,r6rs,r5rs 
    798 == WG1 - Reader Syntax == 
    800 === #12 symbol literal extensions === 
    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. 
    807 R6RS added additional exceptions for symbols beginning with `->`, a 
    808 common idiom, still allowing parsers to determine type with a constant 
    809 lookahead. 
    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. 
    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. 
    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 
    829 === #84 Need to decide on a list of named character escapes === 
    831 The WG has voted to have a list of character names. 
    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. 
    836   * '''Proposals:''' 
    837     * '''r5rs:''' space, newline 
    838     * '''r6rs:''' [ 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 
    844 === #104 list of mnemonic string escapes === 
    846 Similar to #84, we need to choose a specific list of mnemonic escapes 
    847 like \n and \t to be recognized in strings. 
    849   * '''Proposals:''' 
    850     * '''r5rs:''' `\\`, `\"` 
    851     * '''r6rs:''' [ 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. 
     1399=== #195 Editorial: proposed rewording for `begin` === 
     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". 
     1406Suggestion: adopt the language of R6RS section 11.4.7. 
     1408--Andy Wingo 
     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 ...). 
     1414Vote `yes` to adopt the R6RS description, modified for differences in 
     1415the language. 
     1417  * '''Options:''' yes, no, undecided 
     1418  * '''Default:''' no 
     1419  * '''Preferences:''' yes,undecided,no 
     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. 
     1424=== #198 Make it an error for a procedure mapped by MAP and friends to mutate the result list/string/vector === 
     1426This is possibly difficult to enforce, and can break existing R5RS 
     1427programs written in very bad style. 
     1429  * '''Options:''' yes, no, undecided 
     1430  * '''Default:''' no 
     1431  * '''Preferences:''' yes,undecided,no 
     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. 
     1437=== #199 Make it an error for a procedure mapped by MAP and friends to return more than once === 
     1439This is possibly difficult to enforce, and can break existing R5RS 
     1442  * '''Options:''' yes, no, undecided 
     1443  * '''Default:''' no 
     1444  * '''Preferences:''' undecided,yes,no 
     1446Rationale: I would like to know the ramifications of this. 
     1448=== #200 Completing the blob procedures === 
     1450Add `blob`, `blob-map`, `blob-for-each`, and blob conversion functions 
     1451to and from lists/vectors/strings. 
     1453  * '''Options:''' yes, no, undecided 
     1454  * '''Default:''' no 
     1455  * '''Preferences:''' undecided,yes,no 
     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.  
     1460=== #205 Roll partial-blob-copy(!) into blob-copy(!) === 
     1462... with extra arguments. 
     1464  * '''Options:''' yes, no, undecided 
     1465  * '''Default:''' no 
     1466  * '''Preferences:''' yes,undecided,no 
     1468Rationale: This simplifies the name space and should make things easier.  
     1469I like this sort of interface better than remembering another name. 
     1471=== #206 Provide read-syntax for blobs === 
     1473R6RS provides a `#vu8(...)` read-syntax for bytevectors.  SRFI-4 uses 
     1476  * '''Options:''' r6rs, srfi-4, none, undecided 
     1477  * '''Default:''' none 
     1478  * '''Preferences:''' r6rs,srfi-4,undecided,none 
     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. 
     1483=== #207 Editorial: Polar complex numbers are inexact === 
     1485Add a note saying that `1@2` and `(make-polar 1 2)` MAY evaluate to an 
     1486inexact complex number. 
     1488  * '''Options:''' yes, no, undecided 
     1489  * '''Default:''' no 
     1490  * '''Preferences:''' undecided,yes,no 
     1492Rationale: I haven't thought enough about this. 
     1494=== #208 Is || a valid identifier? === 
     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 
     1503<vertical bar> <symbol element>+ <vertical bar> 
     1506Vote `remove` to remove the `|...|` syntax altogether. 
     1508  * '''Options:''' remove, empty-valid, empty-invalid, undecided 
     1509  * '''Default:''' empty-valid 
     1510  * '''Preferences:''' empty-valid,empty-invalid,undecided,removed 
     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. 
     1515=== #191 Include CLOSE-PORT ? === 
     1517Should we include `close-port`, as a generic version of 
     1518`close-input-port` and `close-output-port`? 
     1520  * '''Options:''' yes, no, undecided 
     1521  * '''Default:''' no 
     1522  * '''Preferences:''' yes,no 
     1524Rationale: It's useful and general, but I'm not attached to it. 
     1526=== #188 Clarify wording of `and` and `or` definitions === 
     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. 
     1533R6RS provides a clearer definition that does not provide wiggle room 
     1534for multiple false values. Should we use that? 
     1536  * '''Options:''' yes, no, undecided 
     1537  * '''Default:''' no 
     1538  * '''Preferences:''' yes,undecided,no 
     1540Rationale: We should clarify this wording specifically to eliminate this  
     1541ambiguity about false values. 
     1543=== #187 Clarify duplicate bindings in `let*` === 
     1545The language of the standard could clarify that duplicate bindings are 
     1546permitted in the clauses of a `let*`. 
     1548  * '''Options:''' yes, no, undecided 
     1549  * '''Default:''' no 
     1550  * '''Preferences:''' yes,undecided,no 
     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. 
     1557=== #215 initial value argument to make-blob === 
     1559`make-blob` should either have an initial value argument, or rationale 
     1560why it is inconsistent with `make-vector` and `make-string`. 
     1562Vote `yes` for an initial value argument. 
     1564  * '''Options:''' yes, no, undecided 
     1565  * '''Default:''' no 
     1566  * '''Preferences:''' yes,undecided,no 
     1568Rationale: I assume that this will be an optional argument, so, yes. 
     1570=== #216 Controlling use of reader labels on output === 
     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. 
     1577We could offer a parameter to control this, or have a separate 
     1578procedure (e.g. `write/simple`) which doesn't use the reader labels. 
     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. 
     1584  * '''Options:''' parameter, write/simple, none, undecided 
     1585  * '''Default:''' none 
     1586  * '''Preferences:''' undecided,none,parameter,write/simple 
     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