Changes between Initial Version and Version 1 of WG1Ballot3


Ignore:
Timestamp:
08/21/11 00:41:46 (6 years ago)
Author:
alexshinn
Comment:

archiving third ballot

Legend:

Unmodified
Added
Removed
Modified
  • WG1Ballot3

    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 July 1st = 
     15 
     16= Previous Undecided and Re-opened Ballot Items = 
     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 
     23WG1 voted '''srfi-9''' before.  New arguments against filter 
     24constructors were raised, so the ticket was re-opened. 
     25 
     26References: 
     27  * https://groups.google.com/d/topic/scheme-reports-wg1/BX2F10MO6_k/discussion 
     28 
     29  * '''Proposals:''' 
     30    * '''cowan:''' RecordsCowan 
     31    * '''gleckler:''' RecordsGleckler, which is just RecordsCowan plus RecordsArcfide 
     32    * '''hsu:''' RecordsArcfide 
     33    * '''medernach:''' AggregatesMedernach 
     34    * '''rush:''' UserAggregatesRush 
     35    * '''snellpym:''' UniqueTypesSnellPym 
     36  * '''Options:''' srfi-9, srfi-57, srfi-99, r6rs, cowan, hsu, medernach, rush, snellpym, none, wg2, undecided 
     37  * '''Default:''' srfi-9 
     38  * '''Preferences:'''  
     39 
     40=== #28 Binary I/O ports === 
     41 
     42Do we provide any binary input or output ports, and if so how do we 
     43construct them and operate on them?  Can binary and textual operations 
     44be mixed on the different port types? 
     45 
     46BinaryPortsCowan provided binary port operations, being a mild 
     47revision of the relevant parts of PortsCowan.  It has been removed 
     48by Cowan in favor of PortsShinn. 
     49 
     50PortsShinn provides binary port operations, with similar operations to 
     51BinaryPortsCowan but keeping the binary/textual ports disjoint. 
     52 
     53R6RS provides an entirely new I/O system, as well as a separate 
     54R5RS-compatible I/O system. 
     55 
     56The withdrawn SRFI-91 provides yet another I/O system supporting 
     57binary ports. 
     58 
     59Note this item as well as #29 and #31 specify semi-orthogonal aspects 
     60of I/O systems which are typically specified together by individual 
     61proposals.  If the same proposal doesn't win for all three, the 
     62aspects will be merged as needed. 
     63 
     64WG1 voted weakly in favor of PortsCowan before. 
     65 
     66  * '''Proposals:'''  
     67    * '''r6rs:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.2 R6RS Port I/O] 
     68    * '''r6rs-simple:''' [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_sec_8.3 R6RS Simple I/O] 
     69    * '''srfi-91:''' [http://srfi.schemers.org/srfi-91/srfi-91.html SRFI-91] 
     70    * '''shinn:''' PortsShinn 
     71  * '''Options:''' r6rs, r6rs-simple, srfi-91, cowan, shinn, none, undecided 
     72  * '''Default:''' none 
     73  * '''Preferences:'''  
     74 
     75=== #83 Auxiliary Keywords === 
     76 
     77In R6RS auxiliary keywords (such as `else` in `cond` and `case` forms) 
     78are explicitly exported from the `(rnrs base (6))` library.  Do we 
     79want to bind and export these from the core library? 
     80 
     81If `else` is bound in the default module, then it must be imported at 
     82the call site whenever using it in `cond` or it won't match 
     83hygienically. 
     84 
     85If `else` is '''not''' bound in the default module, then it must not 
     86be bound or imported at the call site whenever using it in `cond` or 
     87it won't match hygienically. 
     88 
     89Another option is to specify for `cond` and `case` that they match the 
     90`else` identifier literally, ignoring any hygiene.  This breaks 
     91compatibility with R5RS and R6RS. 
     92 
     93WG1 voted '''unbound''' previously.  New issues were brought up on the 
     94list so the ticket was re-opened. 
     95 
     96References: 
     97  * [wiki:Keywords] 
     98  * http://lists.scheme-reports.org/pipermail/scheme-reports/2011-April/thread.html 
     99 
     100  * '''Options:''' bound, unbound, unhygienic, undecided 
     101  * '''Default:''' unbound 
     102  * '''Preferences:'''  
     103 
     104=== #3 module naming convention === 
     105 
     106We need a naming convention for the core modules and standard 
     107libraries of the new module system. 
     108 
     109The existing break down is based on John Cowan's earlier proposal of 
     110factorings in items #71, #72, #73, #74, #75, #76, #77, as well as an 
     111I/O module breakdown in PortsCowan.  There have been various tickets 
     112proposing changing this, so we are re-opening the ticket. 
     113 
     114  * '''Proposals:''' 
     115    * '''draft-1:''' the first draft 
     116    * '''r5rs:''' one single module 
     117    * '''r6rs:''' no proposal yet 
     118    * '''cowan:''' ModuleFactoringCowan 
     119    * '''gleckler:''' ModuleFactoringGleckler 
     120    * '''shinn:''' ModuleFactoringShinn 
     121    * '''medernach:''' ModuleFactoringMedernach 
     122  * '''Options:''' draft-1, r5rs, r6rs, cowan, shinn, medernach, undecided 
     123  * '''Default:''' draft-1 
     124  * '''Preferences:'''  
     125 
     126= New Ballot Items = 
     127 
     128== WG1 - Core == 
     129 
     130=== #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? === 
     131 
     132Now that we have blobs, we have to decide what to call them.  R6RS 
     133uses bytevector, SRFI-4 and SRFI-68 uses u8vector, while the original 
     134WG1 proposal used blob (which is therefore the default). 
     135 
     136  * '''Options:''' blob, bytevector, byte-vector, u8vector, octet-vector, undecided 
     137  * '''Default:''' blob 
     138  * '''Preferences:'''  
     139 
     140=== #118 Simple literals must be explicitly delimited. === 
     141 
     142In R5RS syntax such as `#t#f` is left unspecified - some readers may 
     143parse this as the true literal followed by false.  R6RS requires 
     144identifiers, characters, booleans, number objects, and `.` to be 
     145terminated with a "delimiter" or by the end of input. 
     146 
     147References: 
     148  * http://scheme-punks.org/wiki/index.php?title=ERR5RS:Lexical_Syntax 
     149  * http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002649.html 
     150 
     151  * '''Options:''' delimited, unspecified, undecided 
     152  * '''Default:''' unspecified 
     153  * '''Preferences:'''  
     154 
     155=== #119 Whether to treat # as a delimiter. === 
     156 
     157In R5RS `foo#f` is a valid identifier, whereas R6RS requires `#` to 
     158act as a delimiter, so that this would parse as the identifier `foo` 
     159followed by the false literal. 
     160 
     161  * '''Options:'''  delimiter, no, undecided 
     162  * '''Default:''' no 
     163  * '''Preferences:'''  
     164 
     165=== #123 Extend unquote and unquote-splicing to multiple arguments === 
     166 
     167This is a change also made by R6RS (and CL). 
     168 
     169References: 
     170  * http://lists.scheme-reports.org/pipermail/scheme-reports/2011-April/000448.html 
     171  * http://www.rhinocerus.net/forum/lang-scheme/98742-quasiquote-syntax-rules-macro.html 
     172  * http://www.mail-archive.com/guile-user@gnu.org/msg03899.html 
     173 
     174  * '''Options:''' multiple, single, undecided 
     175  * '''Default:''' single 
     176  * '''Preferences:'''  
     177 
     178=== #124 Nested quasiquote semantics === 
     179 
     180References: 
     181  * http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.17 
     182  * http://lists.nongnu.org/archive/html/chicken-hackers/2010-12/msg00008.html 
     183 
     184  * '''Proposals:''' 
     185    * '''r5rs:''' unspecified 
     186    * '''r6rs:''' strict and multiple (implies multiple for #123) 
     187    * '''chicken:''' strict at level 0 (option 2 in second reference) 
     188    * '''strict:''' strict at all levels (R6RS with single for #123) 
     189  * '''Options:''' r5rs, r6rs, chicken, strict, undecided 
     190  * '''Default:''' r5rs 
     191  * '''Preferences:'''  
     192 
     193=== #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) === 
     194 
     195This is a change also made by R6RS, specifically: 
     196 
     197> A quasiquote expression may return either fresh, mutable objects or literal structure 
     198> for any structure that is constructed at run time during the evaluation of the expression. 
     199> Portions that do not need to be rebuilt are always literal 
     200 
     201  * '''Options:''' r6rs, r5rs, undecided 
     202  * '''Default:''' r5rs 
     203  * '''Preferences:'''  
     204 
     205=== #126 Partly specify the mutability of the values of quasiquote structures === 
     206 
     207This is a change also made by R6RS. 
     208 
     209  * '''Options:''' r6rs, r5rs, undecided 
     210  * '''Default:''' r5rs 
     211  * '''Preferences:'''  
     212 
     213=== #127 Specify the dynamic environment of the ''before'' and ''after'' procedures of dynamic-wind === 
     214 
     215R5RS is slightly ambiguous, saying 
     216 
     217> BEFORE is called whenever execution enters the dynamic extent of the 
     218> call to THUNK and AFTER is called whenever it exits that dynamic 
     219> extent. 
     220 
     221without saying clearly whether ''before'' and ''after'' themselves are 
     222called before or after the dynamic extent is entered or exited. 
     223 
     224  * '''Proposals:''' 
     225    * '''outside:''' called outside the dynamic extent (R6RS) 
     226    * '''inside:''' called inside the dynamic extent 
     227    * '''unspecified:''' R5RS 
     228  * '''Options:''' outside, inside, unspecified, undecided 
     229  * '''Default:''' unspecified 
     230  * '''Preferences:'''  
     231 
     232=== #135 let-values and let*-values === 
     233 
     234These R6RS procedures were part of #77 (modularization of multiple 
     235values), but were never explicitly voted up or down by WG1, so I'm 
     236opening a new ticket for them. 
     237 
     238  * '''Options:''' yes, no, module, wg2, undecided 
     239  * '''Default:''' no 
     240  * '''Preferences:'''  
     241 
     242=== #137 Current-seconds semantics still open === 
     243 
     244In issue #70, WG1 voted to make `current-seconds` an optional 
     245procedure, but there is no guidance about what it returns. 
     246 
     247If we choose to specify this further, the big question is whether or 
     248not to include leap seconds - i.e. do we specify it as TAI or POSIX 
     249time (the choice of the epoch itself is less controversial and 
     250defaults to the POSIX epoch).  TAI time has the advantage that it 
     251measures real, unambiguous time, and two calls to current-seconds more 
     252than a second apart are guaranteed to actually differ.  POSIX time has 
     253the advantage of bug-for-bug compatibility with POSIX systems - the 
     254times are ambiguous, but they already have to deal with that. 
     255 
     256The other issue is whether to return an integral number of seconds and 
     257lose the ability to specify subsecond real times, or return an inexact 
     258real (flonum) number of seconds and have to deal with variable 
     259precision depending on the date. 
     260 
     261TimeCowan is equivalent to the `posix-integer` option, and in addition 
     262changes the name to `current-posix-second`. 
     263 
     264  * '''Proposals:''' 
     265    * '''cowan:''' TimeCowan 
     266    * '''posix-integer:''' POSIX time as an exact integer value 
     267    * '''posix-flonum:''' POSIX time as an inexact real value 
     268    * '''tai-integer:''' TAI time as an exact integer value 
     269    * '''tai-flonum:''' TAI time as an inexact real value 
     270  * '''Options:''' cowan, unspecified, undecided, none 
     271  * '''Default:''' unspecified 
     272  * '''Preferences:'''  
     273 
     274=== #147 Allow literal file spec lists in include and include-ci === 
     275 
     276This could allow implementation-specific extensions to support files 
     277don't have character-string names.  On the other hand, such names 
     278probably shouldn't be used as source files, and there are other ways 
     279to support this. 
     280 
     281  * '''Options:''' yes, no, undecided 
     282  * '''Default:''' no 
     283  * '''Preferences:'''  
     284 
     285=== #148 Allow include-ci at top level === 
     286 
     287Currently `include-ci` is allowed as a module declaration but not at top level, 
     288as `include` is. 
     289 
     290  * '''Options:''' yes, no, undecided 
     291  * '''Default:''' no 
     292  * '''Preferences:'''  
     293 
     294=== #149 blob ports === 
     295 
     296We've voted to add string ports, which are character ports backed by 
     297Scheme strings.  Since we have blobs another potential extension is 
     298blob ports, which binary ports backed by blobs.  These are described 
     299in PortsCowan, but it's unclear if they were specifically voted for or 
     300against in the previous ballot. 
     301 
     302  * '''Options:''' cowan, none, undecided 
     303  * '''Default:''' none 
     304  * '''Preferences:'''  
     305 
     306=== #150 cond-expand at top level === 
     307 
     308Currently `cond-expand` is only valid as a module declaration.  Should 
     309we allow it at top level in a program? 
     310 
     311  * '''Options:''' yes, no, undecided 
     312  * '''Default:''' no 
     313  * '''Preferences:'''  
     314 
     315=== #153 Renaming blob procedures === 
     316 
     317The blob procedures don't follow the same system as the rest.  I 
     318propose these changes: 
     319 
     320{{{ 
     321copy-blob => blob-copy 
     322copy-blob! => blob-copy! 
     323partial-blob => blob-copy-partial 
     324copy-partial-blob! -> blob-copy-partial! 
     325}}} 
     326 
     327Note this is modulo the choice of "blob" or "bytevector" 
     328or whichever. 
     329 
     330  * '''Options:''' new, original, remove, undecided 
     331  * '''Default:''' original 
     332  * '''Preferences:'''  
     333 
     334=== #154 Physical newline in a string equivalent to \n (that is, U+000A) === 
     335 
     336R5RS leaves this situation undefined, but R6RS, CL, and most languages 
     337that allow it (C does not) treat physical newline and escaped newline 
     338as equivalent, even if the local representation of line endings is 
     339\r\n or U+0085 or what not.  Another possibility is to treat string literals 
     340broken across lines as errors. 
     341 
     342  * '''Options:''' unix, local, error, unspecified, undecided 
     343  * '''Default:''' unspecified 
     344  * '''Preferences:'''  
     345 
     346=== #155 Make recursively defined code an explicit error === 
     347 
     348Allowing examples like these will make code-walkers (including 
     349compilers and interpreters) excessively complicated: 
     350 
     351#1=(begin (display #\x) . #1#) 
     352 
     353(lambda #2=(a b c #2#) ...) 
     354 
     355(+ . #3=(1 2 3 . #3#)) 
     356 
     357  * '''Options:''' error, unspecified, undecided 
     358  * '''Default:''' unspecified 
     359  * '''Preferences:'''  
     360 
     361=== #156 Replace "an error is signalled" with "an implementation-dependent object is raised as if by `raise`" === 
     362 
     363The following situations are described in draft 1 (and R5RS) with "an 
     364error is signalled": 
     365 
     366 1. The ''file-spec'' given to `call-with-input-file`, 
     367 `call-with-output-file`, `open-input-file`, or `open-output-file` 
     368 represents a file that cannot be opened. 
     369 
     370 2. An end of file is read from a port by `read` after the beginning 
     371 of an object's external representation, but the external 
     372 representation is incomplete and therefore not parsable. 
     373 
     374I propose that in both cases the implementation be required to raise 
     375an exception as if by applying `raise` (that is, non-continuably) to 
     376an implementation-defined object, which means it can be caught by the 
     377R7RS exception system.  Note that there is no requirement to create a 
     378fresh object. 
     379 
     380  * '''Options:''' signal, unspecified, undecided 
     381  * '''Default:''' unspecified 
     382  * '''Preferences:'''  
     383 
     384=== #162 Remove DELAY and FORCE altogether === 
     385 
     386They are present in R4RS and R5RS, but not IEEE Scheme (which is our 
     387baseline).  There are problems with a straightforward implementation 
     388that SRFI 45 fixes, but we voted down SRFI 45.  Given that, we should 
     389consider removing them from the standard altogether.  (Of course this 
     390does not mean compliant implementations can't provide them, it just 
     391means they won't be in a standard module.) 
     392 
     393Since the inconsistency was raised and people are going so far as 
     394to remove these, we can entertain votes for SRFI-45's `lazy` again. 
     395 
     396  * '''Options:''' remove, keep, lazy, undecided 
     397  * '''Default:''' keep 
     398  * '''Preferences:'''  
     399 
     400=== #164 Meaning of char-numeric? === 
     401 
     402The current draft, like R6RS, defines `char-numeric?` according to the 
     403nonexistent Unicode Numeric property.  That has to be fixed.  Options: 
     404 
     405 1. '''Any.''' `char-numeric?` returns `#t` if the character's 
     406 Numeric_Type property value is other than `None`.  This means that 
     407 many hanzi are both alphabetic and numeric. 
     408 
     409 2. (Omitted, because it does not preserve IEEE Scheme) 
     410 
     411 3. '''ASCII.''' Define `char-numeric?` to return `#t` only for ASCII 
     412 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9.  This retains compatibility witht 
     413 R5RS, and we can still use `char-numeric?` to parse numbers, and 
     414 safely use `(- (char->integer c) (char->integer #\0))` to obtain the 
     415 digit value the character represents.  (Note: R5RS programs that use 
     416 `char-numeric?` to parse numbers will break if we adopt the current 
     417 draft's definition of `char-numeric?`).  Gauche, Gambit, and Chicken 
     418 (without the utf8 egg) work like this. 
     419 
     420 4. '''Digit.''' Define `char-numeric?` as equivalent to the 
     421 Numeric_Digit property (general category value of Nd).  Guile 2.0, 
     422 Kawa, Larceny, Ypsilon, Mosh, and IronScheme work like this. 
     423 
     424 5. '''Number.''' Define `char-numeric?` as equivalent to the Number 
     425 property (general category values of Nd, Nl, No).  Scheme48, Chez, 
     426 and Ikarus work like this. 
     427 
     428  * '''Options:''' any, number, digit, ascii, undecided 
     429  * '''Default:''' ascii 
     430  * '''Preferences:'''  
     431 
     432=== #166 Add predicate and accessors for error objects === 
     433 
     434(Email from Vincent Manis) 
     435 
     436Problem: It's impossible to write a portable error handler that writes 
     437out the ''message'' and ''irritants'' that were passed to `error`. 
     438 
     439This comes about because `error` creates an "implementation-defined 
     440object". I would assume that this hides the whole exception class 
     441hierarchy a WG2 implementation might provide. Since the ''message'' 
     442and ''irritants'' arguments to `error` are presumably living in this 
     443implementation-defined object, it should be simple enough to provide 
     444accessors to extract them, so that the above "portable error handler" 
     445can be written. 
     446 
     447Suggestion: Add the following procedures: 
     448 
     449`(error-object? `''object''`)` 
     450 
     451Returns `#t` if ''object'' is something created by `error`, `#f` 
     452otherwise. Any constraints on type disjointness are up to the 
     453implementation. 
     454 
     455`(error-object-message `''object''`)` 
     456 
     457Returns the message of ''object''. 
     458 
     459`(error-object-irritants `''object''`)` 
     460 
     461Returns a list of the irritants of ''object''. 
     462 
     463  * '''Options:''' manis, none, undecided 
     464  * '''Default:''' none 
     465  * '''Preferences:'''  
     466 
     467=== #167 Add constructor for error objects === 
     468 
     469(Email from Vincent Manis) 
     470 
     471Problem: Raising arbitrary objects as exceptions has been found to be 
     472nasty in some other languages (Python and C++ in particular). 
     473 
     474This one is a tad speculative, but I'm reluctant to encourage people 
     475to write things like `(raise 4)`, because of course it doesn't respect 
     476any module boundaries. I think the intent with the descriptions of 
     477`raise` and `raise-continuable` was to allow exception hierarchies to 
     478be added in WG2 without constraining them here. I would suggest adding 
     479a new procedure: 
     480 
     481`(make-error-object `''message''` `''obj'' ...`)` 
     482 
     483to creates the implementation-defined object `error` is supposed to 
     484create, and adding a sentence to the `raise` and `raise-continuable` 
     485entries that says "The effect of applying this procedure to an object 
     486not created via `make-error-object` is implementation-defined." This 
     487allows WG2 to do what it wants regarding exception objects, and to 
     488limit the types of exception objects allowed, without breaking 
     489anything in WG1. `Error` can be defined as: 
     490 
     491{{{ 
     492 (define (error message . objs) 
     493   (raise (apply make-error-object message objs))) 
     494}}} 
     495 
     496 
     497  * '''Options:''' manis, none, undecided 
     498  * '''Default:''' none 
     499  * '''Preferences:'''  
     500 
     501=== #169 Add standard-*-port procedures === 
     502 
     503These return the initial values of the corresponding `current-*-port` 
     504procedures, and can be used to access the implementation-provided 
     505standard input, output, and error streams. 
     506 
     507  * '''Options:''' r6rs, none, undecided 
     508  * '''Default:''' none 
     509  * '''Preferences:'''  
     510 
     511=== #171 Duplicate identifiers in define-record-type === 
     512 
     513What happens if `define-record-type` is specified with two fields that 
     514have the same `accessor` identifiers provided for both fields?  More 
     515generally, we need to say what happens when any two identifiers are 
     516non-unique. 
     517 
     518This ticket deals specifically with the situation where two 
     519identifiers (accessors or mutators) of two field clauses in a 
     520`define-record-type` form are identical. This is not meant to address 
     521field names and what happens or what it means if the field names are 
     522symbolically equivalent but lexically distinct. 
     523 
     524  * '''Options:''' error, unspecified, undecided 
     525  * '''Default:''' unspecified 
     526  * '''Preferences:'''  
     527 
     528=== #173 Unifying BEGINs === 
     529 
     530In R5RS, there are three kinds of BEGINs: 
     531 
     5321) All subforms are expressions; this can be used wherever an 
     533expression can be used.  (4.2.3) 
     534 
     5352) All subforms are definitions; this can be used wherever an internal 
     536definition can be used.  (5.2.2) 
     537 
     5383) Subforms can be definitions or expressions intermixed in any order; 
     539this can be used only at top level.  (In R7RS we extend this to module 
     540top level as well).  (5.1) 
     541 
     542In particular, 
     543 
     544{{{ 
     545(define (x) 
     546 (define y 32) 
     547 (begin 
     548   (define z 45) 
     549   (set! y z)) 
     550 y) 
     551}}} 
     552 
     553is not licensed by any of these provisions, and consequently is not 
     554valid R5RS Scheme.  Nevertheless, all of my usual Schemes accept the 
     555above definition except Scheme48/scsh and SSCM -- actually, SSCM fails 
     556when you invoke x rather than when you define it.  So I'm proposing 
     557that we unify them for R7RS. 
     558 
     559  * '''Options:''' cowan, r5rs, undecided 
     560  * '''Default:''' r5rs 
     561  * '''Preferences:'''  
     562 
     563=== #174 Safe uses of multiple values === 
     564 
     565Currently, uses of `values` where the values are discarded anyway is 
     566illegal, but all the usual Schemes except SCM and SSCM accept them (I 
     567tested with `begin`).  Should we go with something close to the R6RS 
     568wording? 
     569 
     570"The continuations of all non-final expressions within a sequence of 
     571expressions, such as in `lambda`, `begin`, `let`, `let*`, `letrec`, 
     572`letrec*`, `case`, and `cond` forms, take an arbitrary number of 
     573values." 
     574 
     575The definition of `begin` would need to change too: 
     576 
     577{{{ 
     578(define-syntax begin 
     579  (syntax-rules () 
     580    ((begin exp) 
     581     exp) 
     582    ((begin exp1 exp2 ...) 
     583     (call-with-values 
     584         (lambda () exp1) 
     585       (lambda args 
     586         (begin exp2 ...)))))) 
     587}}} 
     588 
     589  * '''Options:''' safe-values, r5rs, undecided 
     590  * '''Default:''' r5rs 
     591  * '''Preferences:'''  
     592 
     593=== #45 Record-let syntax and semantics === 
     594 
     595{{{ 
     596(record-let <record-data> ((<variable> <field>) ...) 
     597  <body>) 
     598}}} 
     599 
     600Where each <variable> is filled with the corresponding data <field> 
     601from <record-data> as in a <let> expression, then the <body> is 
     602evaluated with these bindinds added and last expressions is 
     603returned. It is an error if the <record-data> does not contain 
     604corresponding <fields>. 
     605 
     606Notice that this works directly on the data itself and that the data 
     607may contain more fields than the one cited in the record-let 
     608expression allowing code to be reused for inherited records. 
     609 
     610Do we need to be able to check at runtime if a given record data has 
     611a given field ? 
     612 
     613 
     614  * '''Options:''' record-let, none, undecided 
     615  * '''Default:''' none 
     616  * '''Preferences:'''  
     617 
     618=== #172 Multiple returns from `map` === 
     619 
     620R6RS specifies that `map` does not mutate previous results if there 
     621are multiple returns from map. Should we include this language? 
     622 
     623  * '''Options:''' r6rs, unspecified, undecided 
     624  * '''Default:''' unspecified 
     625  * '''Preferences:'''  
     626 
     627=== #178 Shadowing with internal definitions === 
     628 
     629From Andre Von Tonder: 
     630 
     631On p 19, some shadowing problems that would break lexical scope are 
     632declared to be errors.  However, I believe there are other examples 
     633that shold be errors that are not covered by the report. 
     634  
     635In R6RS a more general criterion was used - please see R6RS for 
     636details. 
     637  
     638Here is an example that does not violate the WG1 report but should be 
     639an error becasue it violates lexical scoping.  It does not violate the 
     640WG1 criterion because the meaning of x is not needed to determine 
     641whether (foo x p ) is a definition. 
     642 
     643{{{ 
     644    (let ((x #f)) 
     645      (let-syntax ((foo (syntax-rules (x) 
     646                          ((_ x y) (define y 'outer)) 
     647                          ((_ _ y) (define y 'inner))))) 
     648        (let () 
     649          (foo x p) 
     650          (define x #f) ;; this should be an error because 
     651                        ;; it shadows the previous line where 
     652                        ;; x has already been used in its outer sense 
     653                        ;; during expansion 
     654          p))) 
     655}}} 
     656 
     657Here is another example that WG1 allows but that would cause violation 
     658of lexical scoping, because the macro would be evaluated first and 
     659treat ... as a placeholder in a region where it is shadowed to be the 
     660variable bound to 1: 
     661 
     662{{{ 
     663    (let () 
     664      (define-syntax list-macro 
     665        (syntax-rules () 
     666          ((_ x ...) (list x ...)))) 
     667      (define ... 1)    ;; This shadows ... in previously expanded macro 
     668                        ;; body and will be a violation of lexical scoping 
     669      (list-macro 1 2)) ;; if the last line evaluates to (1 2) 
     670}}} 
     671 
     672OTOH, it is unclear to me if WG1 allows this or not. 
     673 
     674{{{ 
     675    (let ((x #f)) 
     676      (let-syntax ((foo (syntax-rules (x) 
     677                          ((_ x y) (define y 'outer)) 
     678                          ((_ _ y) (define y 'inner))))) 
     679        (let () 
     680          (define x #f) 
     681          (foo x p) 
     682          p))) 
     683}}} 
     684 
     685  * '''Options:''' r6rs, r5rs, tonder, undecided 
     686  * '''Default:''' r5rs 
     687  * '''Preferences:'''  
     688 
     689== WG1 - Modules == 
     690 
     691=== #112 REPL redefinitions === 
     692 
     693R5RS leaves unspecified the semantics of redefining a standard binding 
     694in the REPL.  Do we want to specify semantics, or some set of allowed 
     695behavior for this in the WG1 standard? 
     696 
     697REPLs may allow redefinition.  The sixteen cases that occur are 
     698redefining to/from syntax/non-syntax locally/imported, and the issue 
     699is what happens to previous references to the definition.  The general 
     700possibilities are: 
     701 
     702  1. redefinition signals an error 
     703  2. previous references are overridden (generally not possible if it the previous definition was syntax) 
     704  3. previous references are preserved (indicating a new binding was created, often preferred if replacing non-syntax with syntax to avoid runtime errors) 
     705  4. the semantics are left unspecified 
     706 
     707So all 64 combinations for these 4 values in the following 4x4 matrix 
     708are feasible: 
     709 
     710|| From/To       || import || import syntax || define || define-syntax || 
     711|| import        ||   ?    ||       ?       ||   ?    ||       ?       || 
     712|| import syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     713|| define        ||   ?    ||       ?       ||   ?    ||       ?       || 
     714|| define-syntax ||   ?    ||       ?       ||   ?    ||       ?       || 
     715 
     716Not all 64 combinations necessarily make sense.  The default from R5RS 
     717is "unspecified", which means all 16 values are unspecified.  Note in 
     718most implementations there is no such thing as a "reference" to 
     719existing syntax, since macros are expanded once, but this is not the 
     720case for SCM or Wraith Scheme. 
     721 
     722  * '''Proposals:''' 
     723    * '''override:''' override for all 16 values (non-syntax to syntax can break closure references) 
     724    * '''preserve:''' preserve for all 16 values (must always create a new definition, not mutate, contrary to most implementations) 
     725    * '''common:''' most common behavior among implementations - override, except preserve for non-syntax to syntax 
     726    * '''simple:''' override, except unspecified for non-syntax to syntax 
     727    * '''dynamic:''' override, except unspecified for syntax to anything (compatible with SCM/Wraith) 
     728  * '''Options:''' override, preserve, common, dynamic, unspecified, undecided 
     729  * '''Default:''' unspecified 
     730  * '''Preferences:'''  
     731 
     732=== #132 Imports override previous imports? === 
     733 
     734The current draft describes importing different bindings for the same 
     735identifier as "an error."  R6RS explicitly requires this to signal an 
     736error.  Do we want to change this? 
     737 
     738This ticket refers only to modules - the top-level semantics are 
     739decided in ticket #112. 
     740 
     741  * '''Options:''' override, preserve, error, unspecified, undecided 
     742  * '''Default:''' error 
     743  * '''Preferences:'''  
     744 
     745=== #160 Interleaving of imports and code in a module === 
     746 
     747Given 
     748 
     749{{{ 
     750   (module (name) 
     751     (begin c1 ...) 
     752     (import (A)) 
     753     (begin c2 ...) 
     754     (import (B)) 
     755     (begin c3 ...)) 
     756}}} 
     757 
     758the intention, reference implementation, and specification from 
     759Scheme48 on which the syntax was based say that all imports establish 
     760the initial environment and then the code is expanded in order, but 
     761interleaving the imports is conceivable. 
     762 
     763  * '''Options:''' shinn, interleave, unspecified, undecided 
     764  * '''Default:''' shinn 
     765  * '''Preferences:'''  
     766 
     767=== #163 Allow modules at the REPL? === 
     768 
     769Should users be allowed to enter a `module` form at the REPL? 
     770 
     771Note that there are actually many varying approaches to generating 
     772moduls at runtime, and Scheme48 and Chibi use an out-of-band REPL 
     773operation to create new modules, leaving the `module` binding open. 
     774 
     775  * '''Options:''' yes, no, unspecified, undecided 
     776  * '''Default:''' no 
     777  * '''Preferences:'''  
     778 
     779=== #141 What are the semantics of modules with respect to separate compilation? === 
     780 
     781ModulesShinn says that the bodies of libraries are evaluated 
     782before any of the bodies of the importing library; does that include, 
     783eg, "at compile time" rather than at "run time"?  It's not clear. 
     784 
     785  * '''Options:''' compile-time, unspecified, undecided 
     786  * '''Default:''' undecided 
     787  * '''Preferences:'''  
     788 
     789=== #158 mutating imports === 
     790 
     791Currently the semantics of calling set! or define 
     792on an imported binding is undefined.  Do we 
     793want to specifically make this an error? 
     794 
     795  * '''Options:''' error, allowed, unspecified, undecided 
     796  * '''Default:''' unspecified 
     797  * '''Preferences:'''  
     798 
     799=== #159 base environments === 
     800 
     801What is the base environment provided by the repl, 
     802scripts, and the result of (scheme-report-environment 7)? 
     803 
     804The intention was the base script environment was empty, 
     805scheme-report-environment was (scheme base), and repls 
     806were an implementation-defined superset thereof, but there 
     807are other options and we need to clarify this. 
     808 
     809  * '''Options:''' shinn, undecided 
     810    * '''shinn:''' intention as described above 
     811  * '''Default:''' shinn 
     812  * '''Preferences:'''  
     813 
     814=== #161 module argument to eval === 
     815 
     816It would be useful to allow modules as an argument to eval in addition 
     817to environments.  This could be done with a special syntax, or just 
     818the module name as a list. 
     819 
     820R6RS provides a procedure `environment` which just 
     821takes a list that looks like an import spec an generates 
     822the corresponding environment. 
     823 
     824  * '''Options:''' r6rs, none, undecided 
     825  * '''Default:''' r6rs 
     826  * '''Preferences:'''  
     827 
     828=== #139 `exit` === 
     829 
     830The ballot statement for #62 said we had voted for `exit` when we 
     831voted for ModulesShinn, but that page doesn't mention `exit`.  So we 
     832need to vote on it. 
     833 
     834  * '''Options:''' yes, no, undecided 
     835  * '''Default:''' yes 
     836  * '''Preferences:'''  
     837 
     838=== #144 strip prefix on import === 
     839 
     840I'm thinking that for importing code that defines its external symbols 
     841as `foo:this`, `foo:that`, and `foo:tother`, there should be a type of 
     842import clause that strips a specified prefix from imported symbols. 
     843This is equivalent to renaming on import or renaming on export, but 
     844less painful, in the same way as the `prefix` import clause does. 
     845 
     846Specific proposal: `(strip-prefix <import-set> <prefix-identifier>)`. 
     847 
     848  * '''Options:''' yes, no, undecided 
     849  * '''Default:''' no 
     850  * '''Preferences:'''  
     851 
     852== WG1 - I/O == 
     853 
     854=== #133 Provide read-line === 
     855 
     856This is an R6RS procedure that was part of PortsCowan, but never 
     857explicitly voted up or down by WG1.  It reads a single line up to a 
     858line delimiter from a given port (the current input by default) and 
     859discards the line delimiter. 
     860 
     861  * '''Options:''' yes, no, undecided 
     862  * '''Default:''' no 
     863  * '''Preferences:'''  
     864 
     865=== #170 Add with-error-to-file procedure === 
     866 
     867Since we now have `current-error-port`, arguably we should have 
     868`with-error-to-file` for completeness. 
     869 
     870  * '''Options:''' yes, no, undecided 
     871  * '''Default:''' no 
     872  * '''Preferences:'''  
     873 
     874=== #176 Are string ports exclusively character ports? === 
     875 
     876From scheme-reports discussion list, by John Cowan: 
     877 
     878> Jeronimo Pellegrini scripsit: 
     879> > According to Section 6.7.1, "Conversely, not all character ports are 
     880> > binary ports -- for example, the /string ports/ discussed below".  It 
     881> > is not really clear to wether the document *requires* string ports not 
     882> > to be binary or if it was just an example of a port that *could* be 
     883> > character but not binary. 
     884> 
     885> I haven't thought about it, but I guess it *could* be the latter, if the 
     886> environment provides a default encoding for string ports. 
     887 
     888  * '''Options:''' character-only, unspecified, undecided 
     889  * '''Default:''' unspecified 
     890  * '''Preferences:'''  
     891 
     892=== #177 Distinguish file and string ports? === 
     893 
     894Should there exist predicates that identify string and file ports? 
     895 
     896  * '''Options:''' string-port?, file-port?, both, neither, undecided 
     897  * '''Default:''' neither 
     898  * '''Preferences:'''  
     899 
     900=== #131 Output procedures return value === 
     901 
     902Output procedures (display, write, newline) currently return 
     903unspecified value, do we wish to make them return something (like in 
     904case of an error) or not? 
     905 
     906Need proposals. 
     907 
     908  * '''Options:''' r5rs, undecided 
     909  * '''Default:'''  
     910  * '''Preferences:'''  
     911 
     912=== #134 Provide flush-output-port === 
     913 
     914This is an R6RS procedure that was part of PortsCowan, but never 
     915explicitly voted up or down by WG1.  It flushes implementation output 
     916buffers on the specified port, the current output port by default. 
     917 
     918  * '''Options:''' yes, no, undecided 
     919  * '''Default:''' no 
     920  * '''Preferences:'''  
     921 
     922== WG1 - Numerics == 
     923 
     924=== #117 Real numbers have imaginary part #e0 === 
     925 
     926In R6RS, a complex number with imaginary part 0 is only real if the 
     927imaginary part is an exact 0.  In R5RS, this was not true, and the 
     928requirement was simply that `(zero? (imag-part Z))` be true. 
     929 
     930  * '''Options:''' exact-only, any-zero, unspecified, undecided 
     931  * '''Default:''' any-zero 
     932  * '''Preferences:'''  
     933 
     934=== #120 Define the semantics of the transcendental functions more fully === 
     935 
     936R6RS has an extended description of the transcendental functions.  Do 
     937we want to include this? 
     938 
     939TODO: explain the exact diff, why it is desirable, and whether any 
     940reasonable alternatives are possible. 
     941 
     942References: 
     943  * http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.7.3.2 
     944 
     945  * '''Options:''' r6rs, r5rs, undecided 
     946  * '''Default:''' r5rs 
     947  * '''Preferences:'''  
     948 
     949=== #121 The semantics of expt for zero bases has been refined === 
     950 
     951This is a change also made by R6RS. 
     952 
     953R5RS says: 
     954 
     955  Returns z1 raised to the power z2. For z1 /= 0, z1^z2^ = e^z2^ log z1; 0^z^ is 1 if z = 0 and 0 otherwise. 
     956 
     957R6RS says: 
     958 
     959  Returns z1 raised to the power z2. For nonzero z1, this is e^z2^ log z1. 0.0^z^ is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive. For other cases in which the first argument is zero, either an exception is raised [...] or an unspecified number object is returned. 
     960 
     961 
     962  * '''Options:''' r6rs, r5rs, undecided 
     963  * '''Default:''' r5rs 
     964  * '''Preferences:'''  
     965 
     966=== #122 Make infinity, NaN, and -0.0 semantics (when supported) consistent with IEEE 754 === 
     967 
     968R5RS does not explicitly describe these values.  We have to decide 
     969whether to require that, if an implementation provides any of these 
     970values, they must be consistent with IEEE 754. 
     971 
     972R6RS both requires these values and requires they be consistent with 
     973IEEE 754. 
     974 
     975  * '''Options:''' ieee-754, unspecified, undecided 
     976  * '''Default:''' unspecified 
     977  * '''Preferences:'''  
     978 
     979=== #175 Control of significant digits or decimal places in NUMBER->STRING === 
     980 
     981Vincent Manis pleads for a way to write numbers with a specified precision: 
     982 
     983http://lists.scheme-reports.org/pipermail/scheme-reports/2011-May/000709.html 
     984 
     985I (Alaric Snell-Pym) wondered if this should be done via 
     986NUMBER->STRING or via an optional extra argument to ROUND etc 
     987specifying a precision, as a number like `0.01` to get two decimal 
     988places. How to provide significant figures rather than DP without 
     989introducing a base-10 dependency is left as an exercise to the reader 
     990(as is the task of deciding if I'm mad for not wanting a base-10 
     991dependency) 
     992 
     993  * '''Options:''' manis, none, undecided 
     994  * '''Default:''' none 
     995  * '''Preferences:'''  
     996 
     997=== #138 DivisionRiastradh domain === 
     998 
     999Zero as a divisor aside, what should the domain of the proposed 
     1000procedures be? 
     1001 
     1002 1. Any real numbers? 
     1003 1. Integers only? 
     1004 1. Exact integers only? 
     1005 
     1006  * '''Options:''' reals, integers, exact-integers 
     1007  * '''Default:'''  
     1008  * '''Preferences:'''  
     1009 
     1010=== #217 DivisionRiastradh exactness preservation === 
     1011 
     1012What about exactness preservation? 
     1013 
     1014 1. Not exactness preserving 
     1015 1. Exactness preserving unless the implementation can prove that an inexact argument can't affect the result (as in the case of an exact zero dividend and an inexact divisor) 
     1016 1. Exactness preserving in all cases 
     1017 
     1018  * '''Options:''' not-exactness-preserving, exactness-preserving, exactness-preserving-unless 
     1019  * '''Default:'''  
     1020  * '''Preferences:'''  
     1021 
     1022=== #140 Removing `quotient`, `remainder`, `modulo` === 
     1023 
     1024Are we removing the IEEE Scheme functions `quotient`, `remainder`, and 
     1025`modulo` from WG1 Scheme?  If so, we need a special justification, due 
     1026to the charter text: 
     1027 
     1028> Existing features of IEEE Scheme may be removed only if a strong 
     1029> case can be made that they are fundamentally flawed. Insofar as 
     1030> practical, the language should be backwards compatible with the IEEE 
     1031> standard, the R5RS standard, and an appropriate subset of the R6RS 
     1032> standard. 
     1033 
     1034Here's what DivisionRiastradh says: 
     1035 
     1036> Unfortunately, most programming languages give nondescript names 
     1037> such as DIV(IDE), QUOT(IENT), MOD(ULO), and REM(AINDER) to these 
     1038> operations. The language should make clear to programmers what 
     1039> division operations their programs are performing, especially when 
     1040> negative dividends and divisors can arise, but perhaps may not often 
     1041> arise during testing. 
     1042> 
     1043> [...] 
     1044 
     1045> The R5RS gives the names `quotient` and `remainder` to the 
     1046> truncating division operator pair, and the name `modulo` to the 
     1047> remainder half of the flooring division operator pair. For all these 
     1048> three procedures in the R5RS, the dividend may be any integer, and 
     1049> the divisor may be any nonzero integer. 
     1050 
     1051On the other hand, we may prefer relegating them to a 
     1052backward-compatibility module. 
     1053 
     1054Vote "yes" to keep, "no" to remove, and "module" to relegate to a 
     1055module. 
     1056 
     1057  * '''Options:''' yes, no, module, undecided 
     1058  * '''Default:''' yes 
     1059  * '''Preferences:'''  
     1060 
     1061=== #151 Extend `finite?` and `nan?` to non-real values === 
     1062 
     1063R6RS specifies the domain of `finite?` and `nan?` as the real numbers 
     1064only.  I propose that `finite?` return `#t` on a non-real value iff 
     1065both the real part and the imaginary part are finite and not `+nan.0`, 
     1066and that `nan?` return `#t` on a non-real value iff either the real or 
     1067the imaginary part is `+nan.0`. 
     1068 
     1069  * '''Proposals:''' 
     1070    * '''cowan:''' the above description 
     1071  * '''Options:''' cowan, unspecified, undecided 
     1072  * '''Default:''' unspecified 
     1073  * '''Preferences:'''  
     1074 
     1075=== #152 exact-integer-sqrt inconsistent with multiple values module === 
     1076 
     1077R5RS does not actually specify any procedures which return multiple 
     1078values, and so the decision to separate multiple values to a module 
     1079was reasonable.  However, we also voted to make `exact-integer-sqrt`, 
     1080which is in the base module, return multiple values, namely the root 
     1081and the remainder.  That would make the procedure useless unless 
     1082multiple values are provided. 
     1083 
     1084We can either make multiple values not a module, make 
     1085`exact-integer-sqrt` return a list (or single integer) rather than 
     1086multiple values, relegate `exact-integer-sqrt` to a new module, remove 
     1087it altogether, or do nothing and leave the inconsistency. 
     1088 
     1089  * '''Options:''' values-in-core, return-list, return-pair, return-root-only, new-module, remove, nothing, undecided 
     1090  * '''Default:''' nothing 
     1091  * '''Preferences:'''  
     1092 
     1093=== #180 Make case and cond clauses into bodies === 
     1094 
     1095Andy Wingo suggests: make the clauses in `case` and `cond` forms 
     1096(without `=>`, naturally) be BODY instances, to allow them to have 
     1097definitions.  It is well defined AFAIK, and costs nothing. 
     1098 
     1099The counter-argument is that it doesn't "look" like the sort of place 
     1100definitions are allowed. 
     1101 
     1102  * '''Options:''' yes, no, undecided 
     1103  * '''Default:''' no 
     1104  * '''Preferences:'''  
     1105 
     1106=== #181 Add WHEN and UNLESS to the base module === 
     1107 
     1108  * '''Options:''' yes, no, undecided 
     1109  * '''Default:''' no 
     1110  * '''Preferences:'''  
     1111 
     1112=== #182 Add WHILE and UNTIL === 
     1113 
     1114These trivial syntaxes add familiarity for new Scheme programmers 
     1115coming from other languages, as will almost always be the case.  LOOP 
     1116is too big and named-LET too alien. 
     1117 
     1118  * '''Options:''' yes, no, undecided 
     1119  * '''Default:''' no 
     1120  * '''Preferences:'''  
     1121 
     1122=== #183 Escaped newline removes following whitespace? === 
     1123 
     1124Andy Wingo suggests the R6RS handling of escaped embedded newlines: 
     1125 
     1126{{{ 
     1127    "asdadf \ 
     1128    asdfadf" 
     1129}}} 
     1130 
     1131in R6RS has the same meaning as "asdf asdfadf".  It allows you to 
     1132nicely indent strings that you need to line-break for width.  I 
     1133suggest that the production 
     1134 
     1135{{{ 
     1136   \ NEWLINE WHITESPACE* 
     1137}}} 
     1138 
     1139within string literals be elided. 
     1140 
     1141Note an alternate method for handling embedded strings with nice 
     1142indentation is scribble syntax. 
     1143 
     1144We voted on various string syntaxes previously but did not 
     1145specifically propose this R6RS extension.  We should have a rationale 
     1146if we don't follow it. 
     1147 
     1148  * '''Options:''' yes, no, undecided 
     1149  * '''Default:''' no 
     1150  * '''Preferences:'''  
     1151 
     1152=== #184 Require CHAR=?, STRING=? etc. to accept arbitrary numbers of arguments? === 
     1153 
     1154R5RS makes a point of specifying that supporting more than two 
     1155arguments is optional.  (Everything not explicitly mentioned is 
     1156optional, so this may have significance.)  R6RS requires accepting 2 
     1157or more arguments.  Currently Racket, Gambit, Guile, Chez, Ikarus, 
     1158Larceny, Ypsilon, Mosh, and Scheme 9 support the feature, whereas 
     1159Gauche, MIT, Chicken, Bigloo, Scheme48/scsh, Kawa, SISC, Chibi, 
     1160STklos, and SSCM don't. 
     1161 
     1162  * '''Options:''' yes, no, undecided 
     1163  * '''Default:''' no 
     1164  * '''Preferences:'''  
     1165 
     1166=== #185 Add sixth "centered" division operator === 
     1167 
     1168From the Guile manual: 
     1169 
     1170* Scheme Procedure: centered/ x y 
     1171* Scheme Procedure: centered-quotient x y 
     1172* Scheme Procedure: centered-remainder x y 
     1173 
     1174These procedures accept two real numbers x and y, where the divisor y 
     1175must be non-zero. centered-quotient returns the integer q and 
     1176centered-remainder returns the real number r such that x = q*y + r and 
     1177-|y/2| <= r < |y/2|. centered/ returns both q and r, and is more 
     1178efficient than computing each separately. 
     1179 
     1180Note that centered-quotient returns x/y rounded to the nearest 
     1181integer. When x/y lies exactly half-way between two integers, the tie 
     1182is broken according to the sign of y. If y > 0, ties are rounded 
     1183toward positive infinity, otherwise they are rounded toward negative 
     1184infinity. This is a consequence of the requirement that -|y/2| <= r < 
     1185|y/2|. 
     1186 
     1187Note that these operators are equivalent to the R6RS operators div0, 
     1188mod0, and div0-and-mod0. 
     1189 
     1190--Andy Wingo 
     1191 
     1192Taylor Campbell thinks these are useless.  We should probably have use 
     1193cases for _any_ division operator we include. 
     1194 
     1195  * '''Options:''' yes, no, undecided 
     1196  * '''Default:''' no 
     1197  * '''Preferences:'''  
     1198 
     1199=== #195 Editorial: proposed rewording for `begin` === 
     1200 
     1201The documentation for `begin' specifies that it is a sequential 
     1202construct; but really it splices as well, and also of course it's a 
     1203keyword for the module system currently.  This is inaccurate of the 
     1204spec to say that "begin is for sequencing". 
     1205 
     1206Suggestion: adopt the language of R6RS section 11.4.7. 
     1207 
     1208--Andy Wingo 
     1209 
     1210We should explain somewhere the four kinds of `begin`s: (begin expr 
     1211...), (begin decl ...), top-level begin, and module-top-level begin. 
     1212Note that R7RS like R5RS does not have (begin decl ... expr ...). 
     1213 
     1214Vote `yes` to adopt the R6RS description, modified for differences in 
     1215the language. 
     1216 
     1217  * '''Options:''' yes, no, undecided 
     1218  * '''Default:''' no 
     1219  * '''Preferences:'''  
     1220 
     1221=== #198 Make it an error for a procedure mapped by MAP and friends to mutate the result list/string/vector === 
     1222 
     1223This is possibly difficult to enforce, and can break existing R5RS 
     1224programs written in very bad style. 
     1225 
     1226  * '''Options:''' yes, no, undecided 
     1227  * '''Default:''' no 
     1228  * '''Preferences:'''  
     1229 
     1230=== #199 Make it an error for a procedure mapped by MAP and friends to return more than once === 
     1231 
     1232This is possibly difficult to enforce, and can break existing R5RS 
     1233programs. 
     1234 
     1235  * '''Options:''' yes, no, undecided 
     1236  * '''Default:''' no 
     1237  * '''Preferences:'''  
     1238 
     1239=== #200 Completing the blob procedures === 
     1240 
     1241Add `blob`, `blob-map`, `blob-for-each`, and blob conversion functions 
     1242to and from lists/vectors/strings. 
     1243 
     1244  * '''Options:''' yes, no, undecided 
     1245  * '''Default:''' no 
     1246  * '''Preferences:'''  
     1247 
     1248=== #205 Roll partial-blob-copy(!) into blob-copy(!) === 
     1249 
     1250... with extra arguments. 
     1251 
     1252  * '''Options:''' yes, no, undecided 
     1253  * '''Default:''' no 
     1254  * '''Preferences:'''  
     1255 
     1256=== #206 Provide read-syntax for blobs === 
     1257 
     1258R6RS provides a `#vu8(...)` read-syntax for bytevectors.  SRFI-4 uses 
     1259`#u8(...)`. 
     1260 
     1261  * '''Options:''' r6rs, srfi-4, none, undecided 
     1262  * '''Default:''' none 
     1263  * '''Preferences:'''  
     1264 
     1265=== #207 Editorial: Polar complex numbers are inexact === 
     1266 
     1267Add a note saying that `1@2` and `(make-polar 1 2)` MAY evaluate to an 
     1268inexact complex number. 
     1269 
     1270  * '''Options:''' yes, no, undecided 
     1271  * '''Default:''' no 
     1272  * '''Preferences:'''  
     1273 
     1274=== #208 Is || a valid identifier? === 
     1275 
     1276The grammar in 7.1.1 allows `||` as an <identifier>. However, page 5 
     1277suggests the `|...|` form is only for convenience (e.g. `|foo bar|` is 
     1278equivalent to `foo\x20;bar`). There's no way to normalise `||` to 
     1279anything without the vertical bars that's a valid identifier. Was that 
     1280intentional, or should the rule be 
     1281 
     1282{{{ 
     1283<vertical bar> <symbol element>+ <vertical bar> 
     1284}}} 
     1285 
     1286Vote `remove` to remove the `|...|` syntax altogether. 
     1287 
     1288  * '''Options:''' remove, empty-valid, empty-invalid, undecided 
     1289  * '''Default:''' empty-valid 
     1290  * '''Preferences:'''  
     1291 
     1292=== #191 Include CLOSE-PORT ? === 
     1293 
     1294Should we include `close-port`, as a generic version of 
     1295`close-input-port` and `close-output-port`? 
     1296 
     1297  * '''Options:''' yes, no, undecided 
     1298  * '''Default:''' no 
     1299  * '''Preferences:'''  
     1300 
     1301=== #188 Clarify wording of `and` and `or` definitions === 
     1302 
     1303The definitions of `and` and `or` may be slightly confusing. Reword 
     1304them to be more clear. One possible hiccup is that the current 
     1305language permits the return of different false values, while a clearer 
     1306wording may preclude this. 
     1307 
     1308R6RS provides a clearer definition that does not provide wiggle room 
     1309for multiple false values. Should we use that? 
     1310 
     1311  * '''Options:''' yes, no, undecided 
     1312  * '''Default:''' no 
     1313  * '''Preferences:'''  
     1314 
     1315=== #187 Clarify duplicate bindings in `let*` === 
     1316 
     1317The language of the standard could clarify that duplicate bindings are 
     1318permitted in the clauses of a `let*`. 
     1319 
     1320  * '''Options:''' yes, no, undecided 
     1321  * '''Default:''' no 
     1322  * '''Preferences:'''  
     1323 
     1324=== #215 initial value argument to make-blob === 
     1325 
     1326`make-blob` should either have an initial value argument, or rationale 
     1327why it is inconsistent with `make-vector` and `make-string`. 
     1328 
     1329Vote `yes` for an initial value argument. 
     1330 
     1331  * '''Options:''' yes, no, undecided 
     1332  * '''Default:''' no 
     1333  * '''Preferences:'''  
     1334 
     1335=== #216 Controlling use of reader labels on output === 
     1336 
     1337There are cases when one does not want to output reader labels for 
     1338shared structure, such as when you don't care (and want the output to 
     1339be more legible), or when you know that the time or space requirements 
     1340to construct the table will be too large. 
     1341 
     1342We could offer a parameter to control this, or have a separate 
     1343procedure (e.g. `write/simple`) which doesn't use the reader labels. 
     1344 
     1345Finer grained control may also let use specify a predicate for which 
     1346values are interesting (e.g. never use labels for strings), or only 
     1347use labels for cycles, etc. 
     1348 
     1349  * '''Options:''' parameter, write/simple, none, undecided 
     1350  * '''Default:''' none 
     1351  * '''Preferences:'''