Changes between Initial Version and Version 1 of WG1Ballot1


Ignore:
Timestamp:
11/20/10 19:19:05 (7 years ago)
Author:
alexshinn
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WG1Ballot1

    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 New Ballot Items = 
     15 
     16= WG1 Ballot Items To Finalize By Oct. 12 = 
     17 
     18== Working Group 1 == 
     19 
     20=== #1 Which VCS do we use? === 
     21 
     22We need a VCS to keep track of changes to the standard as we start 
     23drafting it. 
     24 
     25  * '''Options:''' bzr, darcs, git, hg, monotone, svn, undecided 
     26  * '''Preferences:'''  
     27 
     28== WG1 - Modules == 
     29 
     30=== #2 Module System === 
     31 
     32As per the charter, we need a module system 
     33proposal which allows sharing of code between 
     34implementations. 
     35 
     36This is one issue where we can't default to 
     37the R5RS, since it has no module system. If 
     38we can't come to consensus, we will have to 
     39take the R6RS module system as-is. 
     40 
     41Note the `r6rs--` option is just the 
     42R6RS module system without versioning or 
     43phasing. 
     44 
     45  * '''Proposals:''' 
     46    * '''ganz:''' ModulesGanz 
     47    * '''hsu:''' ModulesAndPackagesArcfide 
     48    * '''shinn:''' ModulesShinn 
     49  * '''Options:''' ganz, hsu, shinn, r6rs, r6rs--, undecided 
     50  * '''Default:''' r6rs 
     51  * '''Preferences:'''  
     52 
     53== WG1 - Core == 
     54 
     55=== #40 SRFI vs. R6RS precedence === 
     56 
     57Given equal technical merit and compatible extensibility for WG2, 
     58should WG1 prefer SRFIs or standardized behaviors from R6RS when faced 
     59with the choice. For example, a version of syntax-violation 
     60vs. syntax-error. 
     61 
     62This is a meta-item, to be used only as a guideline. 
     63 
     64  * '''Options:''' srfi,r6rs,undecided 
     65  * '''Preferences:'''  
     66 
     67=== #37 transcript-on and transcript-off === 
     68 
     69These were relegated to a compatibility library 
     70in R6RS.  Do we want to keep them, drop them, or 
     71move them to a library? 
     72 
     73Yes means to keep them in the core, as in R5RS, 
     74and no means to remove them entirely. 
     75 
     76  * '''Options:''' yes, no, module, wg2, undecided 
     77  * '''Default:''' yes 
     78  * '''Preferences:'''  
     79 
     80=== #38 letrec* === 
     81 
     82R6RS added letrec* and defined the semantics 
     83of internal define to be equivalent.  Do we 
     84want to add this? 
     85 
     86Choose `letrec*` just to add the syntax, `define` to change the 
     87behavior of internal define, or `yes`/`both` for both. 
     88 
     89  * '''Options:''' both, letrec*, define, no, module, wg2, undecided 
     90  * '''Default:''' no 
     91  * '''Preferences:'''  
     92 
     93=== #41 Should we adopt the SRFI-1 extension to MAP and FOR-EACH? === 
     94 
     95This extension allows the list arguments to be of unequal length, and 
     96stops the procedure whenever any of them run out.  R5RS says the lists 
     97''must'' be of the same length, R6RS says they ''should'' be. 
     98 
     99`Yes` to allow unequal length. 
     100 
     101  * '''Options:''' yes, no, wg2, undecided 
     102  * '''Default:''' no 
     103  * '''Preferences:'''  
     104 
     105=== #42 Should we adopt the SRFI-1 extension to ASSOC and MEMBER? === 
     106 
     107This extension accepts a third argument, the equality predicate to be 
     108used.  Alternatively we could use the R6RS predicates ASSP and MEMP. 
     109 
     110  * '''Options:''' srfi-1, r6rs, no, wg2, undecided 
     111  * '''Default:''' no 
     112  * '''Preferences:'''  
     113 
     114=== #33 dynamic-wind === 
     115 
     116New to R5RS, do we reaffirm the sometimes debated dynamic-wind? 
     117 
     118Removing this would require a strong rationale indicating that it's 
     119fundamentally flawed. 
     120 
     121  * '''Options:''' yes, no, module, wg2, undecided 
     122  * '''Default:''' yes 
     123  * '''Preferences:'''  
     124 
     125=== #34 multiple values === 
     126 
     127New to R5RS, do we reaffirm multiple values, specifically the 
     128procedures `call-with-values` and `values`? 
     129 
     130Removing this would require a strong rationale indicating that it's 
     131fundamentally flawed. 
     132 
     133Note if these forms are removed or placed in a module, for consistency 
     134none of the core library should return multiple values (as is the case 
     135in R5RS). 
     136 
     137`Yes` to keep them, `no` to remove them, and `module` to relegate them 
     138to a module. 
     139 
     140  * '''Options:''' yes, no, module, wg2, undecided 
     141  * '''Default:''' yes 
     142  * '''Preferences:'''  
     143 
     144=== #54 optional arguments === 
     145 
     146Scheme's primitive mechanism of improper lambda-lists allows for 
     147optional arguments, but only with extra machinery.  CL, DSSSL, and 
     148some Schemes provide a special word such as `#!optional` in 
     149lambda-lists, showing that the arguments which follow are optional and 
     150may have default values.  SRFI-89 provides both optional and keyword 
     151arguments via `lambda*` and `define*` and without introducing #!foo 
     152special tokens. 
     153 
     154Note the original ticket description mentions `case-lambda`, but this 
     155is easily provided as a separate module, and will be a separate item. 
     156 
     157  * '''Options:''' dsssl, srfi-89, no, wg2, undecided 
     158  * '''Default:''' no 
     159  * '''Preferences:'''  
     160 
     161=== #57 Simple randomness === 
     162 
     163Student programs often want a small amount of randomness, not 
     164necessarily of very high quality.  Shall we provide a simple interface 
     165to a random variables in WG1 Scheme? 
     166 
     167  * '''Proposals:''' 
     168    * '''cowan:''' RandomCowan 
     169  * '''Options:''' cowan, srfi-27, no, wg2, undecided 
     170  * '''Default:''' no 
     171  * '''Preferences:'''  
     172 
     173=== #59 current-error-port === 
     174 
     175Pretty much all Schemes except embedded ones provide a notion of 
     176current error distinct from current output.  Should this be exposed as 
     177a Scheme output port? 
     178 
     179  * '''Options:''' yes, no, module, wg2, undecided 
     180  * '''Default:''' no 
     181  * '''Preferences:'''  
     182 
     183=== #60 Simple file operations === 
     184 
     185Should WG1 provide a module equivalent to the (rnrs files) module? 
     186This provides `delete-file` and `file-exists?`, which are pretty much 
     187necessities for any file-driven programming. 
     188 
     189Note PortsCowan automatically includes these - voting for them here 
     190guarantees them even if not included by a specific proposal. 
     191 
     192  * '''Options:''' yes, no, module, wg2, undecided 
     193  * '''Default:''' no 
     194  * '''Preferences:'''  
     195 
     196=== #64 Consistency in sequence procedures === 
     197 
     198Should we add the 10 procedures mentioned at CompleteSequenceCowan in 
     199order to make the Scheme sequence types consistent?  They are 
     200`make-list copy-list list-set! string-map string-for-each 
     201string->vector copy-vector vector-map vector-for-each vector->string`, 
     202all with the obvious interface and semantics. 
     203 
     204  * '''Options:''' yes, no, module, wg2, undecided 
     205  * '''Default:''' no 
     206  * '''Preferences:'''  
     207 
     208=== #65 Precision indicators === 
     209 
     210R5RS requires that Scheme support five indicators for the precision of 
     211floating-point values, not only the default `e` but also `s`, `f`, 
     212`d`, and `l`.  Only a few Schemes actually support more than one 
     213precision, so this is mostly noise.  Shall we make it an optional 
     214feature? 
     215 
     216  * '''Options:''' required, optional, no, wg2, undecided 
     217  * '''Default:''' required 
     218  * '''Preferences:'''  
     219 
     220=== #66 Add EXACT-INTEGER? === 
     221 
     222Should we add an EXACT-INTEGER? predicate? Currently, to determine 
     223whether a number is both an integer and exact, we must test for both, 
     224which requires some hackery or poor pattern matching to optimize in 
     225existing Scheme implementations. 
     226 
     227  * '''Options:''' yes, no, module, wg2, undecided 
     228  * '''Default:''' no 
     229  * '''Preferences:'''  
     230 
     231=== #44 Testing function arity === 
     232 
     233We would like a standard for checking function arity.  
     234SRFI-102 proposes a way to check function arity: 
     235 
     236  * '''Options:''' srfi-102, no, wg2, undecided 
     237  * '''Default:''' no 
     238  * '''Preferences:'''  
     239 
     240=== #51 support for cyclic structures in primitives === 
     241 
     242list?, length, equal? and other fundamental primitives may diverge 
     243when given cyclic data.  In the former two cases, avoiding this is 
     244simple and not inefficient, and the equivalents are already provided 
     245in SRFI-1.  In the latter case a 
     246[http://www.r6rs.org/r6rs-editors/2006-February/000969.html proposal] 
     247was made and rejected on the R6RS list.  In the former case, R6RS 
     248seems to require `list?` return `#f` and `length` raise an error. 
     249 
     250Do we want to specify the behavior when these primitives encounter 
     251cyclic data? 
     252 
     253Options are `equal?` to specify `equal?` must not terminate on cyclic 
     254input, `r6rs` to specify R6RS behavior for `list?` and `length`, 
     255`srfi-1` to specify the SRFI-1 semantics (where `length` returns `#f`) 
     256and `equal?+r6rs` or `equal?+srfi-1` are options for both. 
     257 
     258  * '''Options:''' equal?, r6rs, srfi-1, equal?+r6rs, equal?+srfi-1, no, wg2, undecided 
     259  * '''Default:''' no 
     260  * '''Preferences:'''  
     261 
     262=== #58 exact-integer-sqrt === 
     263 
     264Should WG1 include `exact-integer-sqrt` from R6RS?  It allows square 
     265root operations in Schemes that don't provide inexact arithmetic, and 
     266has different semantics from `sqrt`, as it rounds its argument down to 
     267the nearest exact square. 
     268 
     269  (exact-integer-sqrt k) => (values s r) ; k = s^2 + r 
     270 
     271`r6rs`/`yes` for R6RS semantics, `list` to use a list instead of MV, 
     272or `single` to only return `s`. 
     273 
     274  * '''Options:''' r6rs, list, single, no, wg2, undecided 
     275  * '''Default:''' no 
     276  * '''Preferences:'''  
     277 
     278=== #61 finite? nan? === 
     279 
     280Shall we add these numeric predicates defined on the IEEE floating 
     281point values from #20? 
     282 
     283  * '''Options:''' yes, no, module, wg2, undecided 
     284  * '''Default:''' no 
     285  * '''Preferences:'''  
     286 
     287=== #63 call/cc short name === 
     288 
     289Should we allow `call/cc` as an equivalent to 
     290`call-with-current-continuation`? 
     291 
     292  * '''Options:''' yes, no, module, wg2, undecided 
     293  * '''Default:''' yes 
     294  * '''Preferences:'''  
     295 
     296=== #53 Implicit BEGIN to implicit LET-NIL === 
     297 
     298In general, in places where an implict BEGIN occurs, it is possible to 
     299change this to an implicit LET-NIL and remain backwards 
     300compatible. Should we do this? 
     301 
     302This is a meta-item to be used as a guideline, and specific places 
     303would need to be brought up for review. 
     304 
     305  * '''Options:''' yes, no, module, wg2, undecided 
     306  * '''Default:''' no 
     307  * '''Preferences:'''  
     308 
     309== WG1 - Exceptions == 
     310 
     311=== #18 Exception System === 
     312 
     313R6RS provided a detailed exception system with 
     314support for raising and catching exceptions, using 
     315a hierarchy of exception types. 
     316 
     317Do we use this, or parts of it, or a new exception 
     318system?  The `r6rs` option is just for the core 
     319exception handling, not the conditions hierarchy. 
     320 
     321  * '''Proposals:''' 
     322    * '''cowan:''' ExceptionHandlingCowan 
     323  * '''Options:''' cowan, r6rs, wg2, none, undecided 
     324  * '''Default:''' none 
     325  * '''Preferences:'''  
     326 
     327=== #17 error === 
     328 
     329Do we support the near ubiquitous SRFI-23 error procedure, 
     330and if so should it use the SRFI-23 signature, R6RS, or 
     331type-dispatch on the first argument to allow both? 
     332 
     333Note ExceptionHandlingCowan currently includes a SRFI-23 compatible 
     334`error` procedure. 
     335 
     336  * '''Options:''' srfi-23, r6rs, both, no, module, wg2, undecided 
     337  * '''Default:''' no 
     338  * '''Preferences:'''  
     339 
     340== WG1 - I/O == 
     341 
     342=== #30 string ports === 
     343 
     344Do we support string ports, as implemented by SRFI-6 
     345or as by R6RS? 
     346 
     347Note that currently PortsCowan provides SRFI-6 string ports. 
     348 
     349  * '''Options:''' srfi-6, r6rs, no, module, wg2, undecided 
     350  * '''Default:''' no 
     351  * '''Preferences:'''  
     352 
     353=== #52 read/write cyclic data === 
     354 
     355SRFI-38 standardizes the #0=(1 . #0#) shared 
     356structure notation for read/write.  In the case 
     357of write, this can be expensive to compute, but 
     358otherwise the common case of the repl printing 
     359a cyclic structure results in an infinite loop. 
     360 
     361Do we want to add support for this, as an option 
     362or separate set of procedures? 
     363 
     364`srfi-38` for separate procedures or `native` to require `read` and 
     365`write` to handle cyclic notation. 
     366 
     367  * '''Options:''' srfi-38, native, no, wg2, undecided 
     368  * '''Default:''' no 
     369  * '''Preferences:'''  
     370 
     371== WG1 - Macros == 
     372 
     373=== #7 (... ...) ellipse escaping in syntax patterns === 
     374 
     375A popular extension, formalized in the R6RS, 
     376is to allow "(... <templ>)" in a syntax-rules template 
     377to be an escape for "<templ>".  Do we use this, and 
     378if so what does (... <t1> <t2>) mean? 
     379 
     380  * '''Options:''' yes, no, wg2, undecided 
     381  * '''Default:''' no 
     382  * '''Preferences:'''  
     383 
     384=== #39 syntax-error === 
     385 
     386Should we have syntax-error parallel to SRFI-23 error?  This is evoked 
     387when macros are expanded. 
     388 
     389  * '''Options:''' yes, no, module, wg2, undecided 
     390  * '''Default:''' no 
     391  * '''Preferences:'''  
     392 
     393=== #5 syntax-rules === 
     394 
     395Do we keep syntax-rules in the core, relegate 
     396it to a standard module, or leave it out entirely 
     397(possibly letting WG2 specify it). 
     398 
     399`Yes` to keep in core, `no` to remove from Scheme entirely. 
     400 
     401  * '''Options:''' yes, no, module, wg2, undecided 
     402  * '''Default:''' yes 
     403  * '''Preferences:'''  
     404 
     405=== #10 identifier syntax === 
     406 
     407R6RS introduced identifier syntax as a way to 
     408expand identifiers in non-macro positions. 
     409 
     410Orthogonal to the overall macro system and what 
     411types of expanders are provided, do we provide 
     412a means to specify identifier syntax? 
     413 
     414  * '''Options:''' yes, no, module, wg2, undecided 
     415  * '''Default:''' no 
     416  * '''Preferences:'''  
     417 
     418=== #47 internal define-syntax === 
     419 
     420R6RS extends define-syntax to be allowed 
     421in local lexical contexts.  Do we allow 
     422this as well? 
     423 
     424  * '''Options:''' yes, no, wg2, undecided 
     425  * '''Default:''' no 
     426  * '''Preferences:'''  
     427 
     428=== #6 syntax-rules _ patterns === 
     429 
     430R6RS adds _ as a wild-card pattern, breaking 
     431some existing R5RS macros.  Do we add the _ wildcard, 
     432or leave it as a normal identifier as in R5RS? 
     433 
     434Yes to add, no for R5RS. 
     435 
     436  * '''Options:''' yes, no, wg2, undecided 
     437  * '''Default:''' no 
     438  * '''Preferences:'''  
     439 
     440=== #8 SRFI-46 ellipse specifier in syntax-rules === 
     441 
     442As an alternative to #7, SRFI-46 proposed 
     443allowing an optional ellipse specified as 
     444an identifier before the literals list in 
     445syntax-rules: 
     446 
     447  (syntax-rules ::: () 
     448     <ellipse now represented as ::: instead of ...>) 
     449 
     450Do we allow this? 
     451 
     452  * '''Options:''' yes, no, wg2, undecided 
     453  * '''Default:''' no 
     454  * '''Preferences:'''  
     455 
     456=== #9 tail patterns in syntax-rules === 
     457 
     458SRFI-46 and R6RS both allow a fixed number of 
     459tail patterns following an ellipsis in a syntax-rules 
     460pattern: 
     461 
     462  (P1 ... Pk Pe <ellipsis> Pm+1 ... Pn) 
     463 
     464R6RS further allows dotted tail patterns 
     465 
     466  (P1 ... Pk Pe <ellipsis> Pm+1 ... Pn . Px) 
     467 
     468where Px only matches a dotted list. 
     469 
     470Do we allow either or both of these extensions? 
     471 
     472  * '''Options:''' tail, dotted-tail, both, no, wg2, undecided 
     473  * '''Default:''' no 
     474  * '''Preferences:'''  
     475 
     476== WG1 - Numerics == 
     477 
     478=== #20 inexact infinities === 
     479 
     480R6RS provides support for inexact infinities 
     481and NaN objects.  Do we keep these, and if so 
     482do we use the same literal syntax and arithmetic 
     483as in R6RS? 
     484 
     485`Yes` to keep them with the same syntax and semantics of R6RS, or 
     486write in a separate proposal for some other syntax/semantics. 
     487 
     488  * '''Options:''' yes, no, wg2, undecided 
     489  * '''Default:''' no 
     490  * '''Preferences:'''  
     491 
     492=== #21 limited type arithmetic === 
     493 
     494R6RS provides libraries for limited type arithmetic on fixnums only 
     495and flonums only (i.e. `fx+`, `fl*` etc.).  Do we want these? 
     496 
     497  * '''Options:''' yes, no, module, wg2, undecided 
     498  * '''Default:''' no 
     499  * '''Preferences:'''  
     500 
     501=== #22 mantissa widths === 
     502 
     503R6RS introduced the concept of mantissa widths 
     504as an alternative to the R5RS #s in numbers. 
     505Do we want either or both of these? 
     506 
     507  * '''Options:''' r5rs, r6rs, both, no, wg2, undecided 
     508  * '''Default:''' no 
     509  * '''Preferences:'''  
     510 
     511== WG1 - Reader Syntax == 
     512 
     513=== #11 case-sensitivity === 
     514 
     515Does the reader fold case by default, and if so how? 
     516 
     517Yes to fold-case (R5RS) no to preserve case (R6RS), additional votes 
     518to come later from specific proposals. 
     519 
     520  * '''Options:''' yes, no, unspecified, undecided 
     521  * '''Default:''' yes 
     522  * '''Preferences:'''  
     523 
     524=== #15 #\foo character names === 
     525 
     526R6RS greatly extends the list of character names, 
     527as well as allowing #\xNN numeric escapes for characters. 
     528Do we allow any or all of these names? 
     529 
     530`mnemonic` for `#\tab` and friends, `numeric` for `#\xNN` as in R6RS, 
     531and `yes`/`both` for both. 
     532 
     533The exact list of added names is to be decided later. 
     534 
     535  * '''Options:''' mnemonic, numeric, both, no, wg2, undecided 
     536  * '''Default:''' no 
     537  * '''Preferences:'''  
     538 
     539=== #13 [brackets] as (parens) === 
     540 
     541R6RS allows [] brackets as identical to parenthesis, 
     542with the condition that they must balance.  Do we 
     543accept this extension, propose some other use for 
     544brackets, or leave them unspecified? 
     545 
     546`Yes` for R6RS, `no` for R5RS, or write in a proposal for some other 
     547meaning for brackets. 
     548 
     549  * '''Options:''' yes, no, module, wg2, undecided 
     550  * '''Default:''' no 
     551  * '''Preferences:'''  
     552 
     553=== #14 alternate comment syntax === 
     554 
     555R6RS provides support for #; nested sexp comments, 
     556and #| ... |# nested block comments.  Do we include 
     557either or both of these? 
     558 
     559  * '''Options:''' sexp, block, both, no, wg2, undecided 
     560  * '''Default:''' no 
     561  * '''Preferences:'''  
     562 
     563=== #16 symbol escapes === 
     564 
     565R6RS provides character escapes in symbols of the form `\xnnnn;`, 
     566where nnnn is 1-5 hex digits.  Do we accept this extension?  Do we 
     567also allow |...| to escape a whole symbol or a part of one? 
     568 
     569In all existing standards pipes are reserved and the |...| syntax is 
     570unspecified.  In most implementations it's recognized, but there are 
     571at least a few implementations where pipes are normal character 
     572constituents. 
     573 
     574  * '''Options:''' numeric, quoted, both, no, wg2, undecided 
     575  * '''Default:''' no 
     576  * '''Preferences:'''  
     577 
     578=== #67 string escapes === 
     579 
     580R6RS provides character escapes in strings of the form \xnnnn;, where 
     581nnnn is 1-5 hex digits, as well as \n, \t etc. C-like escapes for 
     582common control characters. Do we accept either or both of these 
     583extensions? 
     584 
     585  * '''Options:''' numeric, mnemonic, both, no, wg2, undecided 
     586  * '''Default:''' no 
     587  * '''Preferences:'''  
     588 
     589== WG1 - Strings and Chars == 
     590 
     591=== #24 char and string folding === 
     592 
     593R6RS provided operations to alter the case of strings and characters 
     594(upcase, downcase, titlecase and foldcase) using locale-independent 
     595Unicode mappings.  Do we provide equivalent mappings? 
     596 
     597Note in a Unicode implementation individual character casings are 
     598incomplete, and string case is not defined as a simple mapping of case 
     599over the constituent characters. 
     600 
     601Note UnicodeCowan currently provides mappings at both levels. 
     602 
     603  * '''Options:''' strings, chars, both, no, module, wg2, undecided 
     604  * '''Default:''' no 
     605  * '''Preferences:'''  
     606 
     607=== #26 string normalization === 
     608 
     609R6RS provides procedures to explicitly convert 
     610strings back and forth between the four Unicode 
     611normalization forms. 
     612 
     613The previous phrasing of this option was overly vague, referring to 
     614"any form of normalization."  I've had to treat `yes` votes as 
     615undecided for lack of a better default.  If you voted `yes` before 
     616please choose one of the following options or write in your own 
     617proposal. 
     618 
     619  * agnostic - `string-ni=?' etc. provides an API of basic normalization insensitive procedures without explicitly converting the strings, analagous to `string-ci=?' 
     620  * generic - `string-normalize` converts to a single implementation-defined normal form 
     621  * separate - `string-compose-canonical`, `string-decompose-canonical` and `string-decompose-compatibility` gives orthogonal control over the normalization being performed 
     622  * specific - `string-normalize-{nfd,nfc,nfkd,nfkc}` converts explicitly to the four normal forms defined in the Unicode standard 
     623 
     624Note UnicodeCowan currently provides specific normalization 
     625procedures. 
     626 
     627  * '''Options:''' generic, separate, specific, agnostic, no, wg2, undecided 
     628  * '''Default:''' no 
     629  * '''Preferences:'''  
     630 
     631=== #27 string-ref/set! access time === 
     632 
     633R6RS suggests string-ref and string-set! work 
     634in O(1) time, implying strings are implemented 
     635as character arrays.  Do we reaffirm this? 
     636 
     637`Yes` for required constant time. 
     638 
     639  * '''Options:''' yes, no, wg2, undecided 
     640  * '''Default:''' no 
     641  * '''Preferences:'''  
     642 
     643=== #23 character set === 
     644 
     645R5RS said almost nothing about character sets. 
     646R6RS specified full Unicode.  Do we specify a 
     647character set, or limit the options in any way? 
     648 
     649  * '''Proposals:''' 
     650    * '''cowan:''' UnicodeCowan 
     651  * '''Options:''' cowan, r5rs, wg2, undecided 
     652  * '''Default:''' r5rs 
     653  * '''Preferences:'''  
     654 
     655---- 
     656 
     657= WG1 Controversial Ballot Items = 
     658 
     659== WG1 - Core == 
     660 
     661=== #50 Byte-Vectors === 
     662 
     663Several SRFIs, R6RS, and most Scheme implementations 
     664support some sort of uniform packed integer vectors. 
     665In particular, these are necessary for efficient 
     666binary I/O, and for memory mapping, so WG2 will 
     667certainly want them. 
     668 
     669Do we provide a syntax and basic API for these in WG1? 
     670 
     671  * '''Proposals:''' 
     672    * '''cowan:''' BlobAPI 
     673    * '''snellpym:''' BlobsAndSRFI4SnellPym 
     674  * '''Options:''' cowan, snellpym, wg2, none, undecided 
     675  * '''Default:''' none 
     676  * '''Preferences:'''  
     677 
     678=== #69 Parameters === 
     679 
     680Most Scheme implementations provide some form of dynamic bindings such 
     681as those provided by SRFI-39 parameters. 
     682 
     683  * '''Proposals:''' 
     684    * '''cowan:''' ImmutableParametersCowan 
     685    * '''snellpym:''' ParametersSnellPym 
     686  * '''Options:''' cowan, snellpym, srfi-39, wg2, none, undecided 
     687  * '''Default:''' none 
     688  * '''Preferences:'''  
     689 
     690=== #32 user-defined types === 
     691 
     692Do we support any means of creating disjoint 
     693user-defined types, such as in SRFI-9, SRFI-99 
     694or the R6RS record system? 
     695 
     696  * '''Proposals:''' 
     697    * '''hsu:''' RecordsArcfide 
     698    * '''rush:''' UserAggregatesRush 
     699    * '''snellpym:''' UniqueTypesSnellPym 
     700  * '''Options:''' hsu, rush, snellpym, srfi-9, srfi-99, no, wg2, undecided 
     701  * '''Default:''' no 
     702  * '''Preferences:'''  
     703 
     704== WG1 - Libraries == 
     705 
     706=== #36 hash-tables === 
     707 
     708R6RS and SRFI-69 both provide hash-table interfaces. 
     709Do we provide either of these, or try to provide 
     710some primitives on which efficient hash-tables can 
     711be implemented? 
     712 
     713  * '''Options:''' srfi-69, r6rs, no, wg2, undecided 
     714  * '''Default:''' no 
     715  * '''Preferences:'''