Changes between Version 1 and Version 2 of WG1BallotRead


Ignore:
Timestamp:
07/01/11 11:07:09 (6 years ago)
Author:
bitwize
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotRead

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