Changes between Initial Version and Version 1 of WG1Ballot2


Ignore:
Timestamp:
06/05/11 07:22:29 (6 years ago)
Author:
alexshinn
Comment:

moving from WG1Ballot

Legend:

Unmodified
Added
Removed
Modified
  • WG1Ballot2

    v1 v1  
     1= Instructions = 
     2 
     3    * You may list as many of the options as you want in order of preference. 
     4    * Options are comma-delimited (ignoring space) and case-insensitive. 
     5    * You can pipe-delimit (|) options you want to give equal weight to. 
     6    * 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. 
     8    * 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. 
     12    * Abstain on any item by leaving the preferences blank.  
     13 
     14= WG1 Ballot Items To Finalize By Jan. 9 = 
     15 
     16== WG1 - Core == 
     17 
     18=== #32 user-defined types === 
     19 
     20Do we support any means of creating disjoint user-defined types, such 
     21as in SRFI-9, SRFI-99 or the R6RS record system? 
     22 
     23  * '''Proposals:''' 
     24    * '''cowan:''' RecordsCowan 
     25    * '''hsu:''' RecordsArcfide 
     26    * '''medernach:''' AggregatesMedernach 
     27    * '''rush:''' UserAggregatesRush 
     28    * '''snellpym:''' UniqueTypesSnellPym 
     29  * '''Options:''' srfi-9, srfi-57, srfi-99, r6rs, cowan, hsu, medernach, rush, snellpym, none, wg2, undecided 
     30  * '''Default:''' none 
     31  * '''Preferences:'''  
     32 
     33=== #50 byte-vectors === 
     34 
     35Several SRFIs, R6RS, and most Scheme implementations support some sort 
     36of uniform packed integer vectors.  In particular, these are necessary 
     37for efficient binary I/O, and for memory mapping, so WG2 will 
     38certainly want them. 
     39 
     40Do we provide a syntax and basic API for these in WG1? 
     41 
     42  * '''Proposals:''' 
     43    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-3.html#node_chap_2 R6RS byte-vectors] 
     44    * '''cowan:''' BlobAPI 
     45    * '''snellpym:''' BlobsAndSRFI4SnellPym 
     46  * '''Options:''' r6rs, cowan, snellpym, wg2, none, undecided 
     47  * '''Default:''' none 
     48  * '''Preferences:'''  
     49 
     50=== #55 Lazy evaluation === 
     51 
     52R5RS provides a simple mechanism for easy cases of lazy evaluation. 
     53It does not support generalized lazy evaluation, because all built-in 
     54procedures are eager whether they 'need' to be or not.  The relevant 
     55identifiers are `delay` and `force`; they are not present in IEEE 
     56Scheme.  SRFI 45 argues that this pair is insufficient for expressing 
     57common lazy algorithms in a way that preserves tail recursion, and 
     58adds `lazy` (equivalent to `(delay (force ...))`, but acting 
     59atomically) and `eager`.  The semantics of `delay` and `force` remain 
     60downward compatible. 
     61 
     62Vote `srfi-45` to add just the bindings `lazy` and `eager` in addition 
     63to `delay` and `force`, not all of the `srfi-45` utilities.  Vote 
     64`none` to remove `delay` and `force` from the standard. 
     65 
     66  * '''Options:''' r5rs, srfi-45, none, wg2, undecided 
     67  * '''Default:''' r5rs 
     68  * '''Preferences:'''  
     69 
     70=== #57 Random Numbers === 
     71 
     72Random numbers are useful for a wide variety of applications, 
     73including cryptography, statistics, games, simulations and genetic 
     74programming.  Do we want to provide an interface to random number 
     75generation in WG1 Scheme? 
     76 
     77  * '''Proposals:''' 
     78    * '''srfi-27:''' [http://srfi.schemers.org/srfi-27/srfi-27.html SRFI-27] 
     79    * '''cl:''' RandomnessCommonLisp 
     80    * '''cowan:''' RandomCowan 
     81    * '''hsu:''' RandomnessArcfide 
     82  * '''Options:''' srfi-27, cl, cowan, hsu, none, wg2, undecided 
     83  * '''Default:''' none 
     84  * '''Preferences:'''  
     85 
     86=== #62 Environment Variables === 
     87 
     88Currently, there is no standard way to communicate with the context 
     89from which a Scheme program was started.  This has become pretty 
     90standardized over time: a list of strings ("command-line arguments") 
     91and a map from strings to strings ("environment variables") on input, 
     92and a small integer or string on output ("exit value").  Scheme should 
     93recognize these realities. 
     94 
     95We have `command-line` and `exit` from ModulesShinn, so the question 
     96remains if we should add SRFI-98 environment accessors. 
     97 
     98  * '''Options:''' srfi-98, none, wg2, undecided 
     99  * '''Default:''' none 
     100  * '''Preferences:'''  
     101 
     102=== #68 "Undefined value" vs. "undefined values" === 
     103 
     104In R5RS, many procedures and syntax forms return an "undefined value". 
     105In R6RS, the corresponding convention is to return "undefined values", 
     106meaning an undefined number (including zero) of undefined values.  How 
     107shall R7RS go? 
     108 
     109Vote `r5rs` for a single undefined value, `r6rs` for zero or more 
     110undefined values, or `zero` for exactly zero values.  Anything other 
     111than `r5rs` would break R5RS (and IEEE) compatibility. 
     112 
     113  * '''Options:''' r5rs, r6rs, zero, undecided 
     114  * '''Default:''' r5rs 
     115  * '''Preferences:'''  
     116 
     117=== #49 Undefined value API === 
     118 
     119Assuming a single "undefined" value (dependent on the result of #68), 
     120users sometimes want to test for this value.  If we enforce a unique 
     121undefined value, one approach is to generate this value explicitly to 
     122test against, such as `(void)` provided by some implementations. 
     123Alternately we could provide a test such as `undefined?`.  Either 
     124approach breaks compatibility with existing extensions, and may be 
     125prohibitively difficult to implement for compilers lacking a separate 
     126undefined value type.  Some programmers also consider testing for this 
     127value sign of a broken design. 
     128 
     129Vote `generate` for a `(void)` procedure, `test` for `undefined?`, and 
     130`both` for both. 
     131 
     132  * '''Options:''' generate, test, both, none, wg2, undecided 
     133  * '''Default:''' none 
     134  * '''Preferences:'''  
     135 
     136=== #51 support for cyclic structures in primitives === 
     137 
     138list?, length, equal? and other fundamental primitives may diverge 
     139when given cyclic data.  In the former two cases, avoiding this is 
     140simple and not inefficient, and the equivalents are already provided 
     141in SRFI-1.  In the latter case a 
     142[http://www.r6rs.org/r6rs-editors/2006-February/000969.html proposal] 
     143was made and rejected on the R6RS list.  In the former case, R6RS 
     144seems to require `list?` return `#f` and `length` raise an error. 
     145 
     146Do we want to specify the behavior when these primitives encounter 
     147cyclic data? 
     148 
     149Options are `equal?` to specify `equal?` must terminate on cyclic 
     150input, `r6rs` to specify R6RS behavior for `list?` and `length`, 
     151`srfi-1` to specify the SRFI-1 semantics (where `length` returns `#f`) 
     152and `equal?+r6rs` or `equal?+srfi-1` are options for both. 
     153 
     154  * '''Proposals:'''  
     155    * '''equal?:''' `equal?` is required to do proper checks for cyclic structure to not diverge 
     156    * '''r6rs:''' `list?` should return `#f` and `length` raise an error for cyclic lists 
     157    * '''srfi-1:''' `length` is equivalent to `length+` and returns `#f` for a cyclic list 
     158  * '''Options:''' equal?,r6rs,srfi-1,equal?+r6rs,equal?+srfi-1,no,module,wg2,undecided 
     159  * '''Preferences:'''  
     160 
     161=== #69 Dynamic Parameters === 
     162 
     163Old-fashioned Lisps used dynamic extent of variables.  Although Scheme 
     164has switched to lexical scope, the concept of a dynamic environment 
     165can be useful in special cases. 
     166 
     167Instead of special variables, SRFI-39 provides first-class "parameter" 
     168objects with dynamic bindings.  Do we want to provide something 
     169similar? 
     170 
     171  * '''Proposals:''' 
     172    * '''srfi-39:''' [http://srfi.schemers.org/srfi-39/srfi-39.html SRFI-39] 
     173    * '''cowan:''' ImmutableParametersCowan 
     174    * '''snellpym:''' ParametersSnellPym 
     175  * '''Options:''' cowan, snellpym, srfi-39, none, wg2, undecided 
     176  * '''Default:''' none 
     177  * '''Preferences:'''  
     178 
     179=== #70 accessing the system time === 
     180 
     181Short of a full time and date library, a single procedure 
     182 
     183  (current-seconds) 
     184 
     185returning the epoch time in seconds, possibly as a real number, would 
     186be useful and is sufficient to implement a full library (though access 
     187to the host system's timezone would be desirable in that case). 
     188 
     189Since some systems may not have access to a clock, we could make this 
     190an optional procedure.  Alternately, it could be defined as a simple 
     191counter in such cases, providing an accurate notion of time ordering 
     192but no sense of duration. Finally, it could return `#f` in the absense 
     193of a clock. 
     194 
     195  * '''Proposals:''' 
     196    * '''cowan:''' TimeCowan 
     197    * '''required:''' `(current-seconds)` must return seconds since epoch 
     198    * '''optional:''' `(current-seconds)` is an optional procedure 
     199    * '''counter:''' `(current-seconds)` may just be a counter, returning 0, 1, 2, ... 
     200    * '''return-false:''' `(current-seconds)` may return `#f` if unsupported 
     201  * '''Options:''' cowan, required, optional, counter, return-false, none, wg2, undecided 
     202  * '''Default:''' none 
     203  * '''Preferences:'''  
     204 
     205=== #109 elapsed time === 
     206 
     207Should we have functions allowing a program to compute elapsed time, 
     208as distinct from calendar time? 
     209 
     210TimeCowan contains a proposal. 
     211 
     212  * '''Options:''' cowan, yes, no, wg2, undecided 
     213  * '''Default:''' no 
     214  * '''Preferences:'''  
     215 
     216=== #78 Should we have case-lambda? === 
     217 
     218Should we provide case-lambda as in SRFI 16 and R6RS?  It provides 
     219simple overloading of procedures based on the number of their 
     220arguments, and does not require that optional arguments appear only 
     221after mandatory ones. 
     222 
     223  * '''Options:''' yes, no, module, wg2, undecided 
     224  * '''Default:''' no 
     225  * '''Preferences:'''  
     226 
     227=== #82 missing port? procedure === 
     228 
     229It's not clear whether R5RS requires a PORT? procedure or not.  It's 
     230listed in Section 3.3.2 under Disjointness of Types, but not under 
     231section 6.6.1 under Ports.  R6RS requires it.  Racket, Gauche, MIT 
     232Scheme, Gambit, Chicken, Guile, SISC support it; Scheme48/scsh, Kawa, 
     233and Chibi currently do not. 
     234 
     235Shall we require it? 
     236 
     237  * '''Options:''' yes, no, module, wg2, undecided 
     238  * '''Default:''' no 
     239  * '''Preferences:'''  
     240 
     241=== #107 port status detection === 
     242 
     243Currently there's no way to determine whether a port is open or 
     244closed, short of trying to read/write to it and catching an error. 
     245Do we want to add an interface to this? 
     246 
     247  * '''Options:''' port-open?, port-closed?, both, no, wg2, undecided 
     248  * '''Default:''' no 
     249  * '''Preferences:'''  
     250 
     251=== #87 Allow multiple producers in `call-with-values` === 
     252 
     253In R5RS and R6RS, `call-with-values` takes two arguments, both 
     254procedures.  The first is a ''producer'' of multiple values; the 
     255second is a ''consumer'', to which the multiple values returned by 
     256''producer'' are passed as arguments. 
     257 
     258A possible extension is to allow multiple ''producer'' arguments, 
     259flattening all the produced values together, analogous to Common 
     260Lisp's `multiple-value-call`. 
     261 
     262Do we add this extension? 
     263 
     264  * '''Options:''' yes, no, wg2, undecided 
     265  * '''Default:''' no 
     266  * '''Preferences:'''  
     267 
     268=== #88 SRFI 87: => in CASE === 
     269 
     270SRFI-87 extends `case` with a `=>` clauses, analogous to the use of 
     271`=>` in `cond` clauses, which allows you to pass the item actually 
     272matched to a procedure. 
     273 
     274Do we add this extension? 
     275 
     276  * '''Options:''' yes, no, wg2, undecided 
     277  * '''Default:''' no 
     278  * '''Preferences:'''  
     279 
     280=== #89 SRFI 61: COND => with generator and guard === 
     281 
     282SRFI-61 extends `=>` clauses in `cond` with an optional ''guard'' 
     283form, such that after the value is generated and found to be true, 
     284it's further checked against the guard.  If the guard returns `#f` the 
     285clause fails and processing proceeds to the next clause, otherwise the 
     286clause is accepted as normal. 
     287 
     288Do we add this extension? 
     289 
     290  * '''Options:''' yes, no, wg2, undecided 
     291  * '''Default:''' no 
     292  * '''Preferences:'''  
     293 
     294=== #90 Multiple values in COND => clauses === 
     295 
     296Currently, `=>` clauses in `cond` accept a single value from the 
     297''generator'' (right-hand side) and pass it to the ''receiver'' 
     298(left-hand side).  Shall we allow the generator to return multiple 
     299values and pass them to the receiver?  If both this ticket and #89 
     300pass, multiple values would also be allowed for generator/guard `cond` 
     301clauses. 
     302 
     303  * '''Options:''' yes, no, wg2, undecided 
     304  * '''Default:''' no 
     305  * '''Preferences:'''  
     306 
     307=== #91 INCLUDE at the REPL === 
     308 
     309Should we allow `(include "''filename''")` at the REPL?  This is 
     310distinct from `import` in that it just loads code without altering the 
     311module structure. 
     312 
     313  * '''Options:''' yes, no, wg2, undecided 
     314  * '''Default:''' no 
     315  * '''Preferences:'''  
     316 
     317=== #92 Case-folding flags === 
     318 
     319The default reader in R7RS will default to case-sensitive, but users 
     320may wish to override this in some situations.  R6RS allows at the 
     321top-level #!case-fold and #!no-case-fold read syntax to control the 
     322case-sensitivity of the current file.  Many existing R5RS 
     323implementations, on the other hand, use #ci and #cs, with the 
     324difference that they refer to the next datum only. 
     325 
     326Note PortsCowan provides a separate means of controlling 
     327case-sensitivity per-port. 
     328 
     329Vote `per-datum` for the next-datum-only #ci/#cs syntax. 
     330 
     331  * '''Options:''' r6rs, per-datum, none, wg2, undecided 
     332  * '''Default:''' none 
     333  * '''Preferences:'''  
     334 
     335=== #116 Source File Character Encoding === 
     336 
     337The standard currently says nothing about the character encoding 
     338system of source files.  Do we require this to be a fixed encoding 
     339such as UTF-8, use an out-of-band specification like the Emacs (and 
     340Python) `-*- coding: foo -*-` convention, or just leave it 
     341unspecified? 
     342 
     343  * '''Options:''' utf-8, emacs, unspecified, undecided 
     344  * '''Default:''' none 
     345  * '''Preferences:'''  
     346 
     347=== #93 Removing string mutability === 
     348 
     349R6RS relegated `string-set!` to a module, and many modern languages 
     350tend towards making strings immutable.  Removing entirely, however, 
     351breaks IEEE Scheme compatibility and should only be considered if you 
     352believe mutable strings are fundamentally broken. 
     353 
     354Do we remove `string-set!`?  Vote `yes` to remove, `module` to 
     355relegate to a module as in R6RS, or `no` to keep as is. 
     356 
     357  * '''Options:''' yes, no, module, undecided 
     358  * '''Default:''' no 
     359  * '''Preferences:'''  
     360 
     361=== #83 Auxiliary Keywords === 
     362 
     363In R6RS auxiliary keywords (such as `else` in `cond` and `case` forms) 
     364are explicitly exported from the `(rnrs base (6))` library.  Do we 
     365want to bind and export these from the core library? 
     366 
     367If `else` is bound in the default module, then it must be imported at 
     368the call site whenever using it in `cond` or it won't match 
     369hygienically. 
     370 
     371If `else` is '''not''' bound in the default module, then it must not 
     372be bound or imported at the call site whenever using it in `cond` or 
     373it won't match hygienically. 
     374 
     375Another option is to specify for `cond` and `case` that they match the 
     376`else` identifier literally, ignoring any hygiene.  This breaks 
     377compatibility with R5RS and R6RS. 
     378 
     379  * '''Options:''' bound, unbound, unhygienic, undecided 
     380  * '''Preferences:'''  
     381 
     382=== #101 exactness and `eqv?`/`equal?` === 
     383 
     384In R5RS `eqv?`/`equal?` are in some sense the broadest tests for 
     385equality, comparing structural equality, but also tests for the same 
     386exactness, so that 
     387 
     388   {{{(equal? 0 0.0) => #f}}} 
     389 
     390whereas 
     391 
     392   {{{(= 0 0.0) => #t}}} 
     393 
     394Some users consider this confusing, others sometimes want an `equal?` 
     395that behaves like `=` for numbers. 
     396 
     397Do we want to change `equal?` and `eqv?` in this way, or add a 
     398separate exactness-agnostic procedure?  Vote `yes` to change, 
     399`equal=?` or `inexact-equal?` for separate procedures of those names 
     400(plus the analogous `eqv=?` or `inexact-eqv?`), or `no` to leave as 
     401is.  Alternately, write in a separate name. 
     402 
     403  * '''Options:''' yes, equal=?, inexact-equal?, no, wg2, undecided 
     404  * '''Default:''' no 
     405  * '''Preferences:'''  
     406 
     407=== #102 module syntax name === 
     408 
     409A bikeshed color issue, we need to choose the 
     410actual names for the module syntax for the winner 
     411of #2. 
     412 
     413`import`, `export` and `include` are fairly universal 
     414and no alternate is suggested unless someone wants 
     415to write in a proposal. 
     416 
     417The enclosing syntax can be called either 
     418`library` as in R6RS, `module` or some other proposal. 
     419 
     420  * '''Options:''' library, module, undecided 
     421  * '''Default:''' library 
     422  * '''Preferences:'''  
     423 
     424=== #103 module body syntax name === 
     425 
     426Similar to #102, we need to choose a name 
     427for the form to include Scheme code directly 
     428in a module form.  This can be `body` as in 
     429the proposal, `begin` or some other name. 
     430 
     431  * '''Options:''' body, begin, scheme, code, undecided 
     432  * '''Default:''' body 
     433  * '''Preferences:'''  
     434 
     435=== #105 case-insensitive module includes === 
     436 
     437The `include` module form includes files literally 
     438with the default case-sensitivity.  An `include-ci` 
     439form could include files case-insensitively 
     440without resorting to the reader hacks proposed in 
     441#92, allowing existing R5RS libraries to be used 
     442without modification. 
     443 
     444  * '''Options:''' yes, no, wg2, undecided 
     445  * '''Default:''' no 
     446  * '''Preferences:'''  
     447 
     448=== #106 conditional code selection === 
     449 
     450Users invariably want some way to conditionally select code depending 
     451on the implementation and/or feature set available. CondExpandCowan 
     452allows conditional expansion in the style of SRFI-0 within the module language. 
     453[http://srfi.schemers.org/srfi-0/srfi-0.html SRFI-0] provides 
     454`cond-expand`, [http://srfi.schemers.org/srfi-103/srfi-103.html SRFI-103] 
     455provides a library naming extension, and numerous other personal hacks exist. 
     456 
     457Do we want to include something along these lines in WG1 Scheme? 
     458 
     459  * '''Proposals:''' 
     460    * '''cowan:''' CondExpandCowan 
     461    * '''srfi-0:''' `cond-expand` only defined as a top-level module form 
     462    * '''srfi-103:''' the search path extension used by R6RS implementations 
     463  * '''Options:''' cowan, srfi-0, srfi-103, none, wg2, undecided 
     464  * '''Default:''' none 
     465  * '''Preferences:'''  
     466 
     467=== #108 immutable data interface === 
     468 
     469R5RS specifies literal data in source code as immutable, but otherwise 
     470provides no way to generate or introspect immutable data. 
     471 
     472One proposal is given in ImmutableData, providing `mutable?`, 
     473`make-immutable` and `immutable->mutable`. 
     474 
     475Racket, for which all pairs are immutable in the default language, 
     476needs some way to generate shared and cyclic data structures at 
     477runtime, and provides the `shared` syntax for this.  It also has an 
     478`immutable?` utility as the complement to `mutable?` above. 
     479 
     480  * '''Proposals:''' 
     481    * '''medernach:''' ImmutableData 
     482    * '''racket:''' `shared`, `immutable?` ([http://docs.racket-lang.org/reference/shared.html]) 
     483  * '''Options:''' medernach, racket, no, undecided 
     484  * '''Default:''' no 
     485  * '''Preferences:'''  
     486 
     487=== #111 require `equal?` to return `#t` if `eqv?` does === 
     488 
     489Currently `equal?` is strictly broader than `eqv?` except in the 
     490pathological case of comparing the same circular list with itself, for 
     491which `eqv?` returns true and `equal?` may loop infinitely.  We could 
     492explicitly require `equal?` to check and return `#t` in this case, 
     493which most implementations do as a performance hack anyway. 
     494 
     495  * '''Options:''' yes, no, undecided 
     496  * '''Default:''' no 
     497  * '''Preferences:'''  
     498 
     499== WG1 - Exceptions == 
     500 
     501=== #18 exception system === 
     502 
     503R6RS provided a detailed exception system with support for raising and 
     504catching exceptions, using a hierarchy of exception types. 
     505 
     506Do we use this, or parts of it, or a new exception system?  The `r6rs` 
     507option is just for the core exception handling. 
     508 
     509  * '''Proposals:''' 
     510    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-8.html#node_sec_7.1 R6RS Exceptions] - `with-exception-handler`, `guard`, `raise`, `raise-continuable` 
     511    * '''cowan:''' ExceptionHandlingCowan 
     512  * '''Options:''' cowan, r6rs, wg2, none, undecided 
     513  * '''Default:''' none 
     514  * '''Preferences:'''  
     515 
     516=== #19 when to throw an error === 
     517 
     518R5RS defines many things as "is an error" without any specification of 
     519what happens in that situation.  R6RS goes to the opposite extreme and 
     520specifies as much as possible what exceptions are raised when. 
     521 
     522Taking into account the system provided by ticket #18, we need to come 
     523up with guidelines for when exceptions should be raised, and clarify 
     524which R5RS "error" situations should raise an exception or be left 
     525unspecified. 
     526 
     527R5RS specifies only 3 situations where an error is required to be 
     528signalled, leaving most situations unspecified as described in 
     529ErrorSituations. 
     530 
     531  * '''Options:''' r5rs, r6rs, undecided 
     532  * '''Default:''' r5rs 
     533  * '''Preferences:'''  
     534 
     535== WG1 - I/O == 
     536 
     537=== #28 binary I/O ports === 
     538 
     539Do we provide any binary input or output ports, and if so how do we 
     540construct them and operate on them?  Can binary and textual operations 
     541be mixed on the different port types? 
     542 
     543PortsCowan provides binary port operations along with other 
     544extensions. 
     545 
     546R6RS provides an entirely new I/O system, as well as a separate 
     547R5RS-compatible I/O system. 
     548 
     549The withdrawn SRFI-91 provides yet another I/O system supporting 
     550binary ports. 
     551 
     552Note this item as well as #29 and #31 specify semi-orthogonal aspects 
     553of I/O systems which are typically specified together by individual 
     554proposals.  If the same proposal doesn't win for all three, the 
     555aspects will be merged as needed. 
     556 
     557  * '''Proposals:'''  
     558    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
     559    * '''r6rs-simple:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.3 R6RS Simple I/O] 
     560    * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
     561    * '''cowan:''' PortsCowan (subset relevant to binary I/O) 
     562  * '''Options:''' r6rs, r6rs-simple, srfi-91, cowan, none, undecided 
     563  * '''Default:''' none 
     564  * '''Preferences:'''  
     565 
     566=== #29 port encodings === 
     567 
     568Do we support encoding and decoding text from ports with different 
     569character encoding systems?  Different end-of-line conventions? 
     570Different normalizations?  How are encoding errors handled? 
     571 
     572  * '''Proposals:'''  
     573    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
     574    * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
     575    * '''cowan:''' PortsCowan (subset relevant to port encodings) 
     576  * '''Options:''' r6rs, srfi-91, cowan, none, undecided 
     577  * '''Default:''' none 
     578  * '''Preferences:'''  
     579 
     580=== #31 custom ports === 
     581 
     582Do we provide a mechanism for custom ports, on which for instance 
     583string ports could be created? 
     584 
     585R6RS as well as a number of Scheme implementations provide custom 
     586ports with various APIs. 
     587 
     588  * '''Proposals:'''  
     589    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
     590  * '''Options:''' r6rs, none 
     591  * '''Default:''' none 
     592  * '''Preferences:'''  
     593 
     594== WG1 - Libraries == 
     595 
     596=== #36 hash-tables === 
     597 
     598R6RS and SRFI-69 both provide hash-table interfaces.  Do we provide 
     599either of these, or try to provide some primitives on which efficient 
     600hash-tables can be implemented? 
     601 
     602  * '''Options:''' r6rs, srfi-69, no, wg2, undecided 
     603  * '''Default:''' no 
     604  * '''Preferences:'''  
     605 
     606=== #113 directory contents === 
     607 
     608We've decided to add file-exists? and delete-file, 
     609essential for a large class of scripts, but still 
     610have no way to get a list of files in a directory. 
     611Do we want to provide an interface to this? 
     612 
     613  * '''Proposals:''' 
     614    *  '''cowan:''' DirectoryPortsCowan 
     615    *  '''directory-files:''' return a list of all files in the dir 
     616    *  '''directory-streams:''' [http://www.scsh.net/docu/html/man-Z-H-4.html#node_sec_3.3 SCSH directory stream interface] 
     617  * '''Options:''' directory-files, directory-streams, no, wg2, undecided 
     618  * '''Default:''' no 
     619  * '''Preferences:'''  
     620 
     621== WG1 - Macros == 
     622 
     623=== #48 let-syntax === 
     624 
     625`let-syntax` and `letrec-syntax` has known ambiguities in their 
     626behavior. We have the option of altering the semantics to correct this 
     627behavior, defining which behavior we intend, or removing `let-syntax` 
     628entirely.  We could also leave this ambiguity unspecified. 
     629 
     630The question of whether or not to introduce a new lexical scope 
     631(i.e. whether internal `define`s are visible outside the `let-syntax`) 
     632is straightforward. 
     633 
     634If we don't introduce a new lexical scope, the question arises whether 
     635or not internal `define-syntax` forms are allowed and whether they 
     636apply to the body of the `let-syntax`, forms following the 
     637`let-syntax`, or both. 
     638 
     639If internal `define-syntax` applies to the body, we may also wish to 
     640specify what happens when said `define-syntax` redefines an identifier 
     641bound by the enclosing `let-syntax`.  This varies by implementation 
     642and may be difficult for macro expanders to change, so is left 
     643unspecified in the proposals below. 
     644 
     645  * '''Proposals:''' 
     646    * '''hsu:''' LetSyntaxArcfide 
     647    * '''remove:''' remove both of these forms from the standard 
     648    * '''lexical:''' introduces a new lexical contour 
     649    * '''define:''' allows splicing `define`/`begin` 
     650    * '''syntax:''' allows `define-syntax` 
     651    * '''syntax-body:''' allows `define-syntax` only applying to the body 
     652    * '''syntax-follows:'''  allows `define-syntax` only applying to following forms 
     653  * '''Options:''' hsu, remove, lexical, define, syntax, syntax-body, syntax-follows, unspecified, undecided 
     654  * '''Default:''' unspecified 
     655  * '''Preferences:'''  
     656 
     657=== #97 syntax-rules special literals === 
     658 
     659`...` and with the result of #6 also `_` have special meaning in 
     660syntax-rules patterns, so they are not treated as pattern variables by 
     661default. 
     662 
     663However their behavior when used in the literals list of 
     664syntax-rules is ambiguous, and simply breaks in most implementations. 
     665 
     666Rather than breaking, it makes sense to go ahead and treat 
     667them as normal literals, overriding their special meanings. 
     668 
     669In particular, there are many existing R5RS macros which 
     670make use of `_` in the literals and are thus broken outright 
     671by #6. Allowing them as literals fixes these macros. 
     672 
     673  * '''Options:''' literal, error, unspecified, undecided 
     674  * '''Default:''' unspecified 
     675  * '''Preferences:'''  
     676 
     677== WG1 - Modules == 
     678 
     679=== #3 module naming convention === 
     680 
     681We need a naming convention for the core modules and standard 
     682libraries of the new module system. 
     683 
     684In R5RS everything is effectively in a single module.  R6RS provides a 
     685much more fine-grained breakdown of modules which could be 
     686retro-fitted to the bindings we include in our standard. 
     687 
     688John Cowan has proposed a number of module factorings in items #71, 
     689#72, #73, #74, #75, #76, #77, as well as an I/O module breakdown in 
     690PortsCowan. 
     691 
     692Since the naming and breakdown must be internally consistent I'm 
     693grouping these into a single ballot item.  Members desiring to put 
     694forth a new proposal should specify where all bindings belong, or 
     695specify a subset of the bindings and default the rest to some other 
     696proposal. 
     697 
     698Note some ballots specify explicitly whether or not the bindings in 
     699question are intended to be in a module or the core language.  In 
     700these cases we still need to decide to which module they belong. 
     701Where specific votes contradict general factoring proposals, the 
     702specific vote wins. 
     703 
     704  * '''Proposals:''' 
     705    * '''r5rs:''' one single module 
     706    * '''r6rs:''' 
     707    * '''cowan:''' #71, #72, #73, #74, #75, #76, #77 
     708  * '''Options:''' r5rs, r6rs, cowan, undecided 
     709  * '''Default:''' r5rs 
     710  * '''Preferences:'''  
     711 
     712== WG1 - Numerics == 
     713 
     714=== #79 rational-expt === 
     715 
     716Often a rational-only exponentiation function is useful; that is, a 
     717rational number raised to an integer power.  Should we add this 
     718procedure to the core so that exponentiation is available even if 
     719inexact rationals are not provided or not imported? 
     720 
     721  * '''Options:''' yes, no, module, wg2, undecided 
     722  * '''Default:''' no 
     723  * '''Preferences:'''  
     724 
     725=== #81 What numeric tower variants should be supported? === 
     726 
     727NumericTower lists a plausible set of ten from fixnums only to the 
     728full monty.  Which ones should we allow an implementation to provide? 
     729R5RS requires only fixnums large enough to handle string and vector 
     730indexes, while R6RS requires the full numeric tower. 
     731 
     732Vote on '''the minimum level of support''' you want to '''require''' 
     733(implementations may of course still provide more than this).  I've 
     734included only the most likely options below, write in other options if 
     735needed. 
     736 
     737Note quaternions are a fairly rare numeric type, known to be provided 
     738only by extensions to [http://www.ccs.neu.edu/home/dorai/squat/squat.html scm] 
     739and [http://wiki.call-cc.org/eggref/4/quaternions chicken], and thus 
     740may be difficult for other implementations to support if required. 
     741 
     742  * '''Proposals:''' 
     743    * '''r5rs:''' fixnum (`inexact?` may always be false) 
     744    * '''inexact-only:''' inexact (`exact?` may be the same as `integer?`) 
     745    * '''inexact:''' fixnum, inexact 
     746    * '''rational:''' fixnum, inexact, rational 
     747    * '''complex:''' fixnum, inexact, complex 
     748    * '''r6rs:''' fixnum, inexact, rational, complex 
     749    * '''quaternion:''' fixnum, inexact, rational, complex, quaternion 
     750  * '''Options:''' r5rs, inexact-only, inexact, rational, complex, r6rs, quaternion, undecided 
     751  * '''Default:''' r5rs 
     752  * '''Preferences:'''  
     753 
     754=== #100 integral division === 
     755 
     756R5RS provides quotient, modulo and remainder for integral 
     757division. R6RS extended this with div/mod and div0/mod0. A thorough 
     758analysis of possible division operations is provided in 
     759DivisionRiastradh, which includes a proposal for five separate 
     760division operator pairs.  We need to choose which API we'll provide. 
     761 
     762  * '''Proposals:''' 
     763    * '''riastradh:''' DivisionRiastradh 
     764  * '''Options:''' r5rs, r6rs, riastradh, undecided 
     765  * '''Default:''' r5rs 
     766  * '''Preferences:'''  
     767 
     768== WG1 - Reader Syntax == 
     769 
     770=== #12 symbol literal extensions === 
     771 
     772In R5RS, symbols parsed as any sequence of valid symbol characters 
     773that does not begin with a character that can begin a number.  The 
     774three exceptions `+`, `-` and `...` are also provided.  This allows 
     775parsing with only constant lookahead to determine type. 
     776 
     777R6RS added additional exceptions for symbols beginning with `->`, a 
     778common idiom, still allowing parsers to determine type with a constant 
     779lookahead. 
     780 
     781John Cowan proposes allowing anything that cannot be parsed as a 
     782number to be a valid symbol.  This removes the special case 
     783exceptions, but may require arbitrary lookahead. 
     784 
     785Alex Shinn proposes symbols are any sequence of valid symbol 
     786characters that does not have a prefix which is a valid number.  This 
     787removes the special case exceptions, allows constant lookahead, and 
     788allows extensions to number syntax. 
     789 
     790  * '''Proposals:''' 
     791    * '''r5rs:''' symbols may not begin with `-`, except for `-` itself 
     792    * '''r6rs:''' symbols may not begin with `-[^>]` 
     793    * '''cowan:''' symbols are anything that doesn't parse as a number 
     794    * '''shinn:''' symbols may not begin with a number prefix 
     795  * '''Options:''' r5rs, r6rs, cowan, shinn, undecided 
     796  * '''Default:''' r5rs 
     797  * '''Preferences:'''  
     798 
     799=== #84 Need to decide on a list of named character escapes === 
     800 
     801The WG has voted to have a list of character names. 
     802 
     803The list in R5RS and the longer list in R6RS are only informative.  I 
     804suggest adopting the R6RS list and making it normative. 
     805 
     806  * '''Proposals:''' 
     807    * '''r5rs:''' space, newline 
     808    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.6 R6RS Characters] 
     809    * '''shinn:''' space, tab, newline, return, escape, null, alarm, backspace 
     810  * '''Options:''' r5rs, r6rs, shinn 
     811  * '''Default:''' r5rs 
     812  * '''Preferences:'''  
     813 
     814=== #104 list of mnemonic string escapes === 
     815 
     816Similar to #84, we need to choose a specific list of mnemonic escapes 
     817like \n and \t to be recognized in strings. 
     818 
     819  * '''Proposals:''' 
     820    * '''r5rs:''' `\\`, `\"` 
     821    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.7 R6RS Strings] 
     822    * '''shinn:''' `\\`, `\"`, `\t`, `\n`, `\r`, `\e`, `\a`, `\b` 
     823  * '''Options:''' r5rs, r6rs, shinn 
     824  * '''Default:''' r5rs 
     825  * '''Preferences:'''