Changes between Initial Version and Version 1 of WG1Ballot2

06/05/11 07:22:29 (6 years ago)

moving from WG1Ballot


  • WG1Ballot2

    v1 v1  
     1= Instructions = 
     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.  
     14= WG1 Ballot Items To Finalize By Jan. 9 = 
     16== WG1 - Core == 
     18=== #32 user-defined types === 
     20Do we support any means of creating disjoint user-defined types, such 
     21as in SRFI-9, SRFI-99 or the R6RS record system? 
     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:'''  
     33=== #50 byte-vectors === 
     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. 
     40Do 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:'''  
     50=== #55 Lazy evaluation === 
     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. 
     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. 
     66  * '''Options:''' r5rs, srfi-45, none, wg2, undecided 
     67  * '''Default:''' r5rs 
     68  * '''Preferences:'''  
     70=== #57 Random Numbers === 
     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? 
     77  * '''Proposals:''' 
     78    * '''srfi-27:''' [ 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:'''  
     86=== #62 Environment Variables === 
     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. 
     95We have `command-line` and `exit` from ModulesShinn, so the question 
     96remains if we should add SRFI-98 environment accessors. 
     98  * '''Options:''' srfi-98, none, wg2, undecided 
     99  * '''Default:''' none 
     100  * '''Preferences:'''  
     102=== #68 "Undefined value" vs. "undefined values" === 
     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? 
     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. 
     113  * '''Options:''' r5rs, r6rs, zero, undecided 
     114  * '''Default:''' r5rs 
     115  * '''Preferences:'''  
     117=== #49 Undefined value API === 
     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. 
     129Vote `generate` for a `(void)` procedure, `test` for `undefined?`, and 
     130`both` for both. 
     132  * '''Options:''' generate, test, both, none, wg2, undecided 
     133  * '''Default:''' none 
     134  * '''Preferences:'''  
     136=== #51 support for cyclic structures in primitives === 
     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[ 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. 
     146Do we want to specify the behavior when these primitives encounter 
     147cyclic data? 
     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. 
     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:'''  
     161=== #69 Dynamic Parameters === 
     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. 
     167Instead of special variables, SRFI-39 provides first-class "parameter" 
     168objects with dynamic bindings.  Do we want to provide something 
     171  * '''Proposals:''' 
     172    * '''srfi-39:''' [ SRFI-39] 
     173    * '''cowan:''' ImmutableParametersCowan 
     174    * '''snellpym:''' ParametersSnellPym 
     175  * '''Options:''' cowan, snellpym, srfi-39, none, wg2, undecided 
     176  * '''Default:''' none 
     177  * '''Preferences:'''  
     179=== #70 accessing the system time === 
     181Short of a full time and date library, a single procedure 
     183  (current-seconds) 
     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). 
     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. 
     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:'''  
     205=== #109 elapsed time === 
     207Should we have functions allowing a program to compute elapsed time, 
     208as distinct from calendar time? 
     210TimeCowan contains a proposal. 
     212  * '''Options:''' cowan, yes, no, wg2, undecided 
     213  * '''Default:''' no 
     214  * '''Preferences:'''  
     216=== #78 Should we have case-lambda? === 
     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. 
     223  * '''Options:''' yes, no, module, wg2, undecided 
     224  * '''Default:''' no 
     225  * '''Preferences:'''  
     227=== #82 missing port? procedure === 
     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. 
     235Shall we require it? 
     237  * '''Options:''' yes, no, module, wg2, undecided 
     238  * '''Default:''' no 
     239  * '''Preferences:'''  
     241=== #107 port status detection === 
     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? 
     247  * '''Options:''' port-open?, port-closed?, both, no, wg2, undecided 
     248  * '''Default:''' no 
     249  * '''Preferences:'''  
     251=== #87 Allow multiple producers in `call-with-values` === 
     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. 
     258A possible extension is to allow multiple ''producer'' arguments, 
     259flattening all the produced values together, analogous to Common 
     260Lisp's `multiple-value-call`. 
     262Do we add this extension? 
     264  * '''Options:''' yes, no, wg2, undecided 
     265  * '''Default:''' no 
     266  * '''Preferences:'''  
     268=== #88 SRFI 87: => in CASE === 
     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. 
     274Do we add this extension? 
     276  * '''Options:''' yes, no, wg2, undecided 
     277  * '''Default:''' no 
     278  * '''Preferences:'''  
     280=== #89 SRFI 61: COND => with generator and guard === 
     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. 
     288Do we add this extension? 
     290  * '''Options:''' yes, no, wg2, undecided 
     291  * '''Default:''' no 
     292  * '''Preferences:'''  
     294=== #90 Multiple values in COND => clauses === 
     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` 
     303  * '''Options:''' yes, no, wg2, undecided 
     304  * '''Default:''' no 
     305  * '''Preferences:'''  
     307=== #91 INCLUDE at the REPL === 
     309Should we allow `(include "''filename''")` at the REPL?  This is 
     310distinct from `import` in that it just loads code without altering the 
     311module structure. 
     313  * '''Options:''' yes, no, wg2, undecided 
     314  * '''Default:''' no 
     315  * '''Preferences:'''  
     317=== #92 Case-folding flags === 
     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. 
     326Note PortsCowan provides a separate means of controlling 
     327case-sensitivity per-port. 
     329Vote `per-datum` for the next-datum-only #ci/#cs syntax. 
     331  * '''Options:''' r6rs, per-datum, none, wg2, undecided 
     332  * '''Default:''' none 
     333  * '''Preferences:'''  
     335=== #116 Source File Character Encoding === 
     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 
     343  * '''Options:''' utf-8, emacs, unspecified, undecided 
     344  * '''Default:''' none 
     345  * '''Preferences:'''  
     347=== #93 Removing string mutability === 
     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. 
     354Do we remove `string-set!`?  Vote `yes` to remove, `module` to 
     355relegate to a module as in R6RS, or `no` to keep as is. 
     357  * '''Options:''' yes, no, module, undecided 
     358  * '''Default:''' no 
     359  * '''Preferences:'''  
     361=== #83 Auxiliary Keywords === 
     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? 
     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 
     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. 
     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. 
     379  * '''Options:''' bound, unbound, unhygienic, undecided 
     380  * '''Preferences:'''  
     382=== #101 exactness and `eqv?`/`equal?` === 
     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 
     388   {{{(equal? 0 0.0) => #f}}} 
     392   {{{(= 0 0.0) => #t}}} 
     394Some users consider this confusing, others sometimes want an `equal?` 
     395that behaves like `=` for numbers. 
     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. 
     403  * '''Options:''' yes, equal=?, inexact-equal?, no, wg2, undecided 
     404  * '''Default:''' no 
     405  * '''Preferences:'''  
     407=== #102 module syntax name === 
     409A bikeshed color issue, we need to choose the 
     410actual names for the module syntax for the winner 
     411of #2. 
     413`import`, `export` and `include` are fairly universal 
     414and no alternate is suggested unless someone wants 
     415to write in a proposal. 
     417The enclosing syntax can be called either 
     418`library` as in R6RS, `module` or some other proposal. 
     420  * '''Options:''' library, module, undecided 
     421  * '''Default:''' library 
     422  * '''Preferences:'''  
     424=== #103 module body syntax name === 
     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. 
     431  * '''Options:''' body, begin, scheme, code, undecided 
     432  * '''Default:''' body 
     433  * '''Preferences:'''  
     435=== #105 case-insensitive module includes === 
     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. 
     444  * '''Options:''' yes, no, wg2, undecided 
     445  * '''Default:''' no 
     446  * '''Preferences:'''  
     448=== #106 conditional code selection === 
     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[ SRFI-0] provides 
     454`cond-expand`, [ SRFI-103] 
     455provides a library naming extension, and numerous other personal hacks exist. 
     457Do we want to include something along these lines in WG1 Scheme? 
     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:'''  
     467=== #108 immutable data interface === 
     469R5RS specifies literal data in source code as immutable, but otherwise 
     470provides no way to generate or introspect immutable data. 
     472One proposal is given in ImmutableData, providing `mutable?`, 
     473`make-immutable` and `immutable->mutable`. 
     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. 
     480  * '''Proposals:''' 
     481    * '''medernach:''' ImmutableData 
     482    * '''racket:''' `shared`, `immutable?` ([]) 
     483  * '''Options:''' medernach, racket, no, undecided 
     484  * '''Default:''' no 
     485  * '''Preferences:'''  
     487=== #111 require `equal?` to return `#t` if `eqv?` does === 
     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. 
     495  * '''Options:''' yes, no, undecided 
     496  * '''Default:''' no 
     497  * '''Preferences:'''  
     499== WG1 - Exceptions == 
     501=== #18 exception system === 
     503R6RS provided a detailed exception system with support for raising and 
     504catching exceptions, using a hierarchy of exception types. 
     506Do we use this, or parts of it, or a new exception system?  The `r6rs` 
     507option is just for the core exception handling. 
     509  * '''Proposals:''' 
     510    * '''r6rs:''' [ R6RS Exceptions] - `with-exception-handler`, `guard`, `raise`, `raise-continuable` 
     511    * '''cowan:''' ExceptionHandlingCowan 
     512  * '''Options:''' cowan, r6rs, wg2, none, undecided 
     513  * '''Default:''' none 
     514  * '''Preferences:'''  
     516=== #19 when to throw an error === 
     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. 
     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 
     527R5RS specifies only 3 situations where an error is required to be 
     528signalled, leaving most situations unspecified as described in 
     531  * '''Options:''' r5rs, r6rs, undecided 
     532  * '''Default:''' r5rs 
     533  * '''Preferences:'''  
     535== WG1 - I/O == 
     537=== #28 binary I/O ports === 
     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? 
     543PortsCowan provides binary port operations along with other 
     546R6RS provides an entirely new I/O system, as well as a separate 
     547R5RS-compatible I/O system. 
     549The withdrawn SRFI-91 provides yet another I/O system supporting 
     550binary ports. 
     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. 
     557  * '''Proposals:'''  
     558    * '''r6rs:''' [ R6RS Port I/O] 
     559    * '''r6rs-simple:''' [ R6RS Simple I/O] 
     560    * '''srfi-91:''' [ 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:'''  
     566=== #29 port encodings === 
     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? 
     572  * '''Proposals:'''  
     573    * '''r6rs:''' [ R6RS Port I/O] 
     574    * '''srfi-91:''' [ SRFI-91] 
     575    * '''cowan:''' PortsCowan (subset relevant to port encodings) 
     576  * '''Options:''' r6rs, srfi-91, cowan, none, undecided 
     577  * '''Default:''' none 
     578  * '''Preferences:'''  
     580=== #31 custom ports === 
     582Do we provide a mechanism for custom ports, on which for instance 
     583string ports could be created? 
     585R6RS as well as a number of Scheme implementations provide custom 
     586ports with various APIs. 
     588  * '''Proposals:'''  
     589    * '''r6rs:''' [ R6RS Port I/O] 
     590  * '''Options:''' r6rs, none 
     591  * '''Default:''' none 
     592  * '''Preferences:'''  
     594== WG1 - Libraries == 
     596=== #36 hash-tables === 
     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? 
     602  * '''Options:''' r6rs, srfi-69, no, wg2, undecided 
     603  * '''Default:''' no 
     604  * '''Preferences:'''  
     606=== #113 directory contents === 
     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? 
     613  * '''Proposals:''' 
     614    *  '''cowan:''' DirectoryPortsCowan 
     615    *  '''directory-files:''' return a list of all files in the dir 
     616    *  '''directory-streams:''' [ SCSH directory stream interface] 
     617  * '''Options:''' directory-files, directory-streams, no, wg2, undecided 
     618  * '''Default:''' no 
     619  * '''Preferences:'''  
     621== WG1 - Macros == 
     623=== #48 let-syntax === 
     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. 
     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. 
     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. 
     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. 
     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:'''  
     657=== #97 syntax-rules special literals === 
     659`...` and with the result of #6 also `_` have special meaning in 
     660syntax-rules patterns, so they are not treated as pattern variables by 
     663However their behavior when used in the literals list of 
     664syntax-rules is ambiguous, and simply breaks in most implementations. 
     666Rather than breaking, it makes sense to go ahead and treat 
     667them as normal literals, overriding their special meanings. 
     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. 
     673  * '''Options:''' literal, error, unspecified, undecided 
     674  * '''Default:''' unspecified 
     675  * '''Preferences:'''  
     677== WG1 - Modules == 
     679=== #3 module naming convention === 
     681We need a naming convention for the core modules and standard 
     682libraries of the new module system. 
     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. 
     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 
     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 
     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. 
     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:'''  
     712== WG1 - Numerics == 
     714=== #79 rational-expt === 
     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? 
     721  * '''Options:''' yes, no, module, wg2, undecided 
     722  * '''Default:''' no 
     723  * '''Preferences:'''  
     725=== #81 What numeric tower variants should be supported? === 
     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. 
     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 
     737Note quaternions are a fairly rare numeric type, known to be provided 
     738only by extensions to [ scm] 
     739and [ chicken], and thus 
     740may be difficult for other implementations to support if required. 
     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:'''  
     754=== #100 integral division === 
     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. 
     762  * '''Proposals:''' 
     763    * '''riastradh:''' DivisionRiastradh 
     764  * '''Options:''' r5rs, r6rs, riastradh, undecided 
     765  * '''Default:''' r5rs 
     766  * '''Preferences:'''  
     768== WG1 - Reader Syntax == 
     770=== #12 symbol literal extensions === 
     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. 
     777R6RS added additional exceptions for symbols beginning with `->`, a 
     778common idiom, still allowing parsers to determine type with a constant 
     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. 
     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. 
     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:'''  
     799=== #84 Need to decide on a list of named character escapes === 
     801The WG has voted to have a list of character names. 
     803The list in R5RS and the longer list in R6RS are only informative.  I 
     804suggest adopting the R6RS list and making it normative. 
     806  * '''Proposals:''' 
     807    * '''r5rs:''' space, newline 
     808    * '''r6rs:''' [ R6RS Characters] 
     809    * '''shinn:''' space, tab, newline, return, escape, null, alarm, backspace 
     810  * '''Options:''' r5rs, r6rs, shinn 
     811  * '''Default:''' r5rs 
     812  * '''Preferences:'''  
     814=== #104 list of mnemonic string escapes === 
     816Similar to #84, we need to choose a specific list of mnemonic escapes 
     817like \n and \t to be recognized in strings. 
     819  * '''Proposals:''' 
     820    * '''r5rs:''' `\\`, `\"` 
     821    * '''r6rs:''' [ R6RS Strings] 
     822    * '''shinn:''' `\\`, `\"`, `\t`, `\n`, `\r`, `\e`, `\a`, `\b` 
     823  * '''Options:''' r5rs, r6rs, shinn 
     824  * '''Default:''' r5rs 
     825  * '''Preferences:'''