Changes between Version 2 and Version 3 of WG1BallotSnellPym


Ignore:
Timestamp:
08/19/10 01:33:23 (7 years ago)
Author:
alaric
Comment:

Updated my ballot

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotSnellPym

    v2 v3  
    11= WG1 New Ballot Items = 
    22 
    3 Notes about voting: 
     3Notes about results: 
    44 
    55  * you may list as many of the options as you want in order of preference 
     
    1313  * items up for final vote will be marked as such (none are final now) 
    1414 
     15== WG1 - Modules == 
     16 
     17=== 2 Module System === 
     18 
     19As per the charter, we need a module system 
     20proposal which allows sharing of code between 
     21implementations. 
     22 
     23This is one issue where we can't default to 
     24the R5RS, since it has no module system. If 
     25we can't come to consensus, we will have to 
     26take the R6RS module system as-is. 
     27 
     28  * '''Proposals:''' 
     29    * '''hsu:''' ModulesAndPackagesArcfide 
     30    * '''shinn:''' ModulesShinn 
     31  * '''Options:''' hsu, shinn, r6rs, undecided 
     32  * '''Preferences:''' undecided 
     33 
    1534== WG1 - Core == 
    1635 
    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   * '''Options:''' yes,no,module,wg2,undecided 
    24   * '''Preferences:''' no,module 
    25  
    26 === 38 letrec* === 
    27  
    28 R6RS added letrec* and defined the semantics 
    29 of internal define to be equivalent.  Do we 
    30 want to add this? 
    31  
    32   * '''Options:''' yes,no,module,wg2,undecided 
    33   * '''Preferences:''' module,yes 
    34  
    35 I don't see letrec* as being a large burden to implementors, and having it available to define internal define in terms of tidies up a few loose ends. However, I'm all for putting it in a module as it's a "library" tool that could be implemented on top of the core as a macro. 
    36  
    37 === 41 Should we adopt the SRFI-1 extension to MAP and FOR-EACH? === 
    38  
    39 This extension allows the list arguments to be of unequal length, and 
    40 stops the procedure whenever any of them run out.  R5RS says the lists 
    41 ''must'' be of the same length, R6RS says they ''should'' be. 
    42  
    43 `Yes` to allow unequal length. 
    44  
    45   * '''Options:''' yes,no,module,wg2,undecided 
    46   * '''Preferences:''' yes,module 
    47  
    48 Shouldn't be a large burden, and removes a 'hole' in the semantics of map/for-each. 
    49  
    50 === 42 Should we adopt the SRFI-1 extension to ASSOC and MEMBER? === 
    51  
    52 This extension accepts a third argument, the equality predicate to be 
    53 used.  Alternatively we could use the R6RS predicates ASSP and MEMP. 
    54  
    55   * '''Options:''' srfi-1,r6rs,no,module,wg2,undecided 
    56   * '''Preferences:''' srfi-1,r6rs 
    57  
    58 The SRFI-1 form just strikes me as neater. 
     36=== 50 Byte-Vectors === 
     37 
     38Several SRFIs, R6RS, and most Scheme implementations 
     39support some sort of uniform packed integer vectors. 
     40In particular, these are necessary for efficient 
     41binary I/O, and for memory mapping, so WG2 will 
     42certainly want them. 
     43 
     44Do we provide a syntax and basic API for these in WG1? 
     45 
     46  * '''Proposals:''' 
     47    * '''cowan:''' BlobAPI 
     48    * '''snellpym:''' BlobsAndSRFI4SnellPym 
     49  * '''Options:''' cowan, snellpym, wg2, none, undecided 
     50  * '''Preferences:''' snellpym, cowan, wg2, none 
     51 
     52=== 69 Parameters === 
     53 
     54Most Scheme implementations provide some form of dynamic bindings such 
     55as those provided by SRFI-39 parameters. 
     56 
     57  * '''Proposals:''' 
     58    * '''cowan:''' ImmutableParametersCowan 
     59    * '''snellpym:''' ParametersSnellPym 
     60  * '''Options:''' cowan, snellpym, srfi-39, wg2, none, undecided 
     61  * '''Preferences:''' cowan, snellpym, srfi-39, wg2 
     62 
     63Unusually, I prefer the Cowan proposal over my own, as I actually like immutability. However, many people don't, and my proposal is to ensure that (given the concession of mutability), the interaction between threads is handled in a way that lets developers make useful assumptions. 
     64 
     65== WG1 - Exceptions == 
     66 
     67=== 18 Exception System === 
     68 
     69R6RS provided a detailed exception system with 
     70support for raising and catching exceptions, using 
     71a hierarchy of exception types. 
     72 
     73Do we use this, or parts of it, or a new exception 
     74system? 
     75 
     76  * '''Proposals:''' 
     77    * '''cowan:''' ExceptionHandlingCowan 
     78  * '''Options:''' cowan, wg2, none, undecided 
     79  * '''Preferences:''' cowan, wg2, none 
     80 
     81---- 
     82 
     83= WG1 Controversial Ballot Items = 
     84 
     85== WG1 - Core == 
    5986 
    6087=== 40 SRFI vs. R6RS precedence === 
     
    6895  * '''Preferences:''' srfi 
    6996 
    70 I think the SRFI process makes me happier than the R6RS process did. 
    71  
    7297=== 32 user-define types === 
    7398 
     
    77102 
    78103  * '''Proposals:''' 
     104    * '''hsu:''' RecordsArcfide 
     105    * '''rush:''' UserAggregatesRush 
    79106    * '''snellpym:''' UniqueTypesSnellPym 
    80     * '''hsu:''' RecordsArcfide 
    81   * '''Options:''' snellpym,hsu,srfi-9,no,wg2,undecided 
    82   * '''Preferences:''' snellpym,hsu,srfi-9,wg2,no 
    83  
    84 === 33 dynamic-wind === 
    85  
    86 New to R5RS, do we reaffirm the sometimes debated dynamic-wind? 
    87  
    88   * '''Options:''' yes,no,module,wg2,undecided 
    89   * '''Preferences:''' yes,module,wg2,no 
    90  
    91 It's essential for maintaing certain kinds of invariants in the presence of continuation trickery, even though people misunderstand it sometimes. 
    92  
    93 === 34 multiple values === 
    94  
    95 New to R5RS, do we reaffirm multiple values, specifically the 
    96 procedures `call-with-values` and `values`? 
    97  
    98   * '''Options:''' yes,no,module,wg2,undecided 
    99   * '''Preferences:''' yes,module,wg2,no 
     107  * '''Options:''' hsu,rush,snellpym,srfi-9,srfi-99,no,wg2,undecided 
     108  * '''Preferences:''' snellpym.hsu,srfi-99,srfi-9,wg2,no 
    100109 
    101110=== 51 support for cyclic structures in primitives === 
     
    113122  * '''Preferences:''' yes,module,wg2,no 
    114123 
    115 If not, it becomes all to easy to inadvertently apply one of these primitives to data from untrusted sources, introducing denial of service attacks. 
     124=== 58 exact-integer-sqrt === 
     125 
     126Should WG1 include `exact-integer-sqrt` from R6RS?  It allows square 
     127root operations in Schemes that don't provide inexact arithmetic, and 
     128has different semantics from `sqrt`, as it rounds its argument down to 
     129the nearest exact square. 
     130 
     131  * '''Options:''' yes,no,module,wg2,undecided 
     132  * '''Preferences:''' module,yes,wg2 
     133 
     134=== 61 finite? nan? === 
     135 
     136Shall we add these numeric predicates? 
     137 
     138  * '''Options:''' yes,no,module,wg2,undecided 
     139  * '''Preferences:''' yes,module 
     140 
     141=== 63 call/cc short name === 
     142 
     143Should we allow `call/cc` as an equivalent to 
     144`call-with-current-continuation`? 
     145 
     146  * '''Options:''' yes,no,module,wg2,undecided 
     147  * '''Preferences:''' no,module 
     148 
     149=== 53 Implicit BEGIN to implicit LET-NIL === 
     150 
     151In general, in places where an implict BEGIN occurs, it is possible to 
     152change this to an implicit LET-NIL and remain backwards 
     153compatible. Should we do this? 
     154 
     155  * '''Options:''' yes,no,module,wg2,undecided 
     156  * '''Preferences:''' undecided 
     157 
     158== WG1 - I/O == 
     159 
     160=== 52 read/write cyclic data === 
     161 
     162SRFI-38 standardizes the #0=(1 . #0#) shared 
     163structure notation for read/write.  In the case 
     164of write, this can be expensive to compute, but 
     165otherwise the common case of the repl printing 
     166a cyclic structure results in an infinite loop. 
     167 
     168Do we want to add support for this, as an option 
     169or separate set of procedures? 
     170 
     171  * '''Options:''' yes,no,module,wg2,undecided 
     172  * '''Preferences:''' yes,module 
     173 
     174Much as it pains me to require more complexity from WG1 implementations, I feel that there is a security issue here that primitives should not diverge on cyclic structures, as it would make it all too easy to introduce unexpected denial of service opportunities. 
     175 
     176 
     177== WG1 - Libraries == 
     178 
     179=== 36 hash-tables === 
     180 
     181R6RS and SRFI-69 both provide hash-table interfaces. 
     182Do we provide either of these, or try to provide 
     183some primitives on which efficient hash-tables can 
     184be implemented? 
     185 
     186  * '''Options:''' srfi-69,r6rs,no,module,wg2,undecided 
     187  * '''Preferences:''' module,no,srfi-69 
     188 
     189I like providing primitives, but wouldn't want to force hash tables to be available to the user in WG1 implementations; they can ask for SRFI-69 if they want it. 
     190 
     191== WG1 - Macros == 
     192 
     193=== 6 syntax-rules _ patterns === 
     194 
     195R6RS adds _ as a wild-card pattern, breaking 
     196some existing R5RS macros.  Do we add the _ wildcard, 
     197or leave it as a normal identifier as in R5RS? 
     198 
     199Yes to add, no for R5RS. 
     200 
     201  * '''Options:''' yes,no,wg2,undecided 
     202  * '''Preferences:''' no 
     203 
     204=== 8 SRFI-46 ellipse specifier in syntax-rules === 
     205 
     206As an alternative to #7, SRFI-46 proposed 
     207allowing an optional ellipse specified as 
     208an identifier before the literals list in 
     209syntax-rules: 
     210 
     211  (syntax-rules ::: () 
     212     <ellipse now represented as ::: instead of ...>) 
     213 
     214Do we allow this? 
     215 
     216  * '''Options:''' yes,no,module,wg2,undecided 
     217  * '''Preferences:''' yes 
     218 
     219=== 9 tail patterns in syntax-rules === 
     220 
     221SRFI-46 and R6RS both allow a fixed number of 
     222tail patterns following an ellipsis in a syntax-rules 
     223pattern: 
     224 
     225  (P1 ... Pk Pe <ellipsis> Pm+1 ... Pn) 
     226 
     227R6RS further allows dotted tail patterns 
     228 
     229  (P1 ... Pk Pe <ellipsis> Pm+1 ... Pn . Px) 
     230 
     231where Px only matches a dotted list. 
     232 
     233Do we allow either or both of these extensions? 
     234 
     235  * '''Options:''' tail,dotted-tail,both,no,module,wg2,undecided 
     236  * '''Preferences:''' undecided 
     237 
     238== WG1 - Numerics == 
     239 
     240=== 21 limited type arithmetic === 
     241 
     242R6RS provides libraries for limited type arithmetic 
     243on fixnums only and flonums only.  Do we want these? 
     244 
     245  * '''Options:''' yes,no,module,wg2,undecided 
     246  * '''Preferences:''' no,wg2,module 
     247 
     248=== 22 mantissa widths === 
     249 
     250R6RS introduced the concept of mantissa widths 
     251as an alternative to the R5RS #s in numbers. 
     252Do we want either or both of these? 
     253 
     254  * '''Options:''' r5rs,r6rs,both,no,wg2,undecided 
     255  * '''Preferences:''' undecided 
     256 
     257== WG1 - Reader Syntax == 
     258 
     259=== 11 case-sensitivity === 
     260 
     261Does the reader fold case by default, and if so how? 
     262 
     263Yes to fold-case (R5RS) no to preserve case (R6RS), additional votes 
     264to come later from specific proposals. 
     265 
     266  * '''Options:''' yes,no,undecided 
     267  * '''Preferences:''' no 
     268 
     269== Working Group 1 == 
     270 
     271=== 1 Which VCS do we use? === 
     272 
     273There is the question of the right VCS to use. I prefer 
     274Monotone. Currently we are having an email vote on the list. I have 
     275entered this ticket to play with the Trac ticketing system. We can 
     276finalize the ticket once we have chosen a VCS. 
     277 
     278  * '''Options:''' bzr,darcs,git,hg,monotone,svn,undecided 
     279  * '''Preferences:''' git,hg,svn 
     280 
     281---- 
     282 
     283= WG1 Old Items = 
     284 
     285== WG1 - Core == 
     286 
     287=== 37 transcript-on and transcript-off === 
     288 
     289These were relegated to a compatibility library 
     290in R6RS.  Do we want to keep them, drop them, or 
     291move them to a library? 
     292 
     293Yes means to keep them in the core, as in R5RS, 
     294and no means to remove them entirely. 
     295 
     296  * '''Options:''' yes,no,module,wg2,undecided 
     297  * '''Preferences:''' no,wg2,module 
     298 
     299=== 38 letrec* === 
     300 
     301R6RS added letrec* and defined the semantics 
     302of internal define to be equivalent.  Do we 
     303want to add this? 
     304 
     305  * '''Options:''' yes,no,module,wg2,undecided 
     306  * '''Preferences:''' module,yes 
     307 
     308I don't see letrec* as being a large burden to implementors, and having it available to define internal define in terms of tidies up a few loose ends. However, I'm all for putting it in a module as it's a "library" tool that could be implemented on top of the core as a macro. 
     309 
     310=== 41 Should we adopt the SRFI-1 extension to MAP and FOR-EACH? === 
     311 
     312This extension allows the list arguments to be of unequal length, and 
     313stops the procedure whenever any of them run out.  R5RS says the lists 
     314''must'' be of the same length, R6RS says they ''should'' be. 
     315 
     316`Yes` to allow unequal length. 
     317 
     318  * '''Options:''' yes,no,module,wg2,undecided 
     319  * '''Preferences:''' yes,module 
     320 
     321Shouldn't be a large burden, and removes a 'hole' in the semantics of map/for-each. 
     322 
     323=== 42 Should we adopt the SRFI-1 extension to ASSOC and MEMBER? === 
     324 
     325This extension accepts a third argument, the equality predicate to be 
     326used.  Alternatively we could use the R6RS predicates ASSP and MEMP. 
     327 
     328  * '''Options:''' srfi-1,r6rs,no,module,wg2,undecided 
     329  * '''Preferences:''' srfi-1,r6rs 
     330 
     331The SRFI-1 form just strikes me as neater. 
     332 
     333=== 33 dynamic-wind === 
     334 
     335New to R5RS, do we reaffirm the sometimes debated dynamic-wind? 
     336 
     337  * '''Options:''' yes,no,module,wg2,undecided 
     338  * '''Preferences:''' yes,module,wg2,no 
     339 
     340It's essential for maintaining certain kinds of invariants in the presence of continuation trickery, even though people misunderstand it sometimes. 
     341 
     342=== 34 multiple values === 
     343 
     344New to R5RS, do we reaffirm multiple values, specifically the 
     345procedures `call-with-values` and `values`? 
     346 
     347  * '''Options:''' yes,no,module,wg2,undecided 
     348  * '''Preferences:''' yes,module,wg2,no 
    116349 
    117350=== 54 optional arguments === 
     
    140373  * '''Preferences:''' no 
    141374 
    142 srfi-27 can be asked for by name if it's wanted. 
    143  
    144 === 58 exact-integer-sqrt === 
    145  
    146 Should WG1 include `exact-integer-sqrt` from R6RS?  It allows square 
    147 root operations in Schemes that don't provide inexact arithmetic, and 
    148 has different semantics from `sqrt`, as it rounds its argument down to 
    149 the nearest exact square. 
    150  
    151   * '''Options:''' yes,no,module,wg2,undecided 
    152   * '''Preferences:''' module,yes,wg2 
    153  
    154375=== 59 current-error-port === 
    155376 
     
    163384I vote for 'module' since it's not something that EVERY implementation will have, but many will. 
    164385 
     386 
    165387=== 60 Simple file operations === 
    166388 
     
    171393  * '''Options:''' yes,no,module,wg2,undecided 
    172394  * '''Preferences:''' module,yes,wg2 
    173  
    174 === 61 finite? nan? === 
    175  
    176 Shall we add these numeric predicates? 
    177  
    178   * '''Options:''' yes,no,module,wg2,undecided 
    179   * '''Preferences:''' yes,module 
    180  
    181 === 63 call/cc short name === 
    182  
    183 Should we allow `call/cc` as an equivalent to 
    184 `call-with-current-continuation`? 
    185  
    186   * '''Options:''' yes,no,module,wg2,undecided 
    187   * '''Preferences:''' no,module 
    188  
    189 People can trivially define it if they want it. 
    190395 
    191396=== 64 Consistency in sequence procedures === 
     
    202407Consistent sequence types give me a warm feeling of symmetry. 
    203408 
     409 
    204410=== 65 Precision indicators === 
    205411 
     
    221427 
    222428  * '''Options:''' yes,no,module,wg2,undecided 
    223   * '''Preferences:''' yes,module 
     429  * '''Preferences:''' yes, module 
    224430 
    225431=== 44 Testing function arity === 
     
    231437  * '''Preferences:''' undecided 
    232438 
    233 === 53 Implicit BEGIN to implicit LET-NIL === 
    234  
    235 In general, in places where an implict BEGIN occurs, it is possible to 
    236 change this to an implicit LET-NIL and remain backwards 
    237 compatible. Should we do this? 
    238  
    239   * '''Options:''' yes,no,module,wg2,undecided 
    240   * '''Preferences:''' undecided 
    241  
    242439== WG1 - Exceptions == 
    243440 
    244441=== 17 error === 
    245442 
    246 Do we support the near ubiquitous SRFI-23 error procedure? 
    247  
    248   * '''Options:''' srfi-23,r6rs,both,no,module,wg2,undecided  
    249   * '''Preferences:''' srfi-23,module 
    250  
    251 == WG1 - I/O === 
     443Do we support the near ubiquitous SRFI-23 error procedure, 
     444and if so should it use the SRFI-23 signature, R6RS, or 
     445type-dispatch on the first argument to allow both? 
     446 
     447  * '''Options:''' srfi-23,r6rs,both,no,module,wg2,undecided 
     448  * '''Preferences:''' srfi-23 
     449 
     450== WG1 - I/O == 
    252451 
    253452=== 30 string ports === 
    254453 
    255 Do we support SRFI-6 string ports, reaffirmed by R6RS? 
     454Do we support string ports, as implemented by SRFI-6 
     455or as by R6RS? 
    256456 
    257457  * '''Options:''' srfi-6,r6rs,no,module,wg2,undecided 
     
    260460Implementations can provide SRFI-6 through the usual mechanisms, rather than it being put into WG1 
    261461 
    262 === 52 read/write cyclic data === 
    263  
    264 SRFI-38 standardizes the #0=(1 . #0#) shared 
    265 structure notation for read/write.  In the case 
    266 of write, this can be expensive to compute, but 
    267 otherwise the common case of the repl printing 
    268 a cyclic structure results in an infinite loop. 
    269  
    270 Do we want to add support for this, as an option 
    271 or separate set of procedures? 
    272  
    273   * '''Options:''' yes,no,module,wg2,undecided 
    274   * '''Preferences:''' yes,module 
    275  
    276 Much as it pains me to require more complexity from WG1 implementations, I feel that there is a security issue here that primitives should not diverge on cyclic structures, as it would make it all too easy to introduce unexpected denial of service opportunities. 
    277  
    278 == WG1 - Libraries == 
    279  
    280 === 36 hash-tables === 
    281  
    282 R6RS and SRFI-69 both provide hash-table interfaces. 
    283 Do we provide either of these, or try to provide 
    284 some primitives on which efficient hash-tables can 
    285 be implemented? 
    286  
    287   * '''Options:''' srfi-69,r6rs,no,module,wg2,undecided 
    288   * '''Preferences:''' module,no,srfi-69 
    289  
    290 I like providing primitives, but wouldn't want to force hash tables to be available to the user in WG1 implementations; they can ask for SRFI-69 if they want it. 
    291462 
    292463== WG1 - Macros == 
    293  
    294 === 6 syntax-rules _ and ... patterns === 
    295  
    296 R6RS adds _ as a wild-card pattern, breaking 
    297 some existing R5RS macros.  Do we keep the _? 
    298  
    299   * '''Options:''' yes,no,wg2,undecided 
    300   * '''Preferences:''' no 
    301464 
    302465=== 7 (... ...) ellipse escaping in syntax patterns === 
     
    310473  * '''Preferences:''' no 
    311474 
    312 === 8 SRFI-46 ellipse specifier in syntax-rules === 
    313  
    314 As an alternative to #7, SRFI-46 proposed 
    315 allowing an optional ellipse specified as 
    316 an identifier before the literals list in 
    317 syntax-rules: 
    318  
    319   (syntax-rules ::: () 
    320      <ellipse now represented as ::: instead of ...>) 
    321  
    322 Do we allow this? 
    323  
    324   * '''Options:''' yes,no,module,wg2,undecided 
    325   * '''Preferences:''' yes 
    326  
    327 === 9 tail patterns in syntax-rules === 
    328  
    329 SRFI-46 and R6RS both allow a fixed number of 
    330 tail patterns following an ellipsis in a syntax-rules 
    331 pattern: 
    332  
    333   (P1 ... Pk Pe <ellipsis> Pm+1 ... Pn) 
    334  
    335 R6RS further allows dotted tail patterns 
    336  
    337   (P1 ... Pk Pe <ellipsis> Pm+1 ... Pn . Px) 
    338  
    339 where Px only matches a dotted list. 
    340  
    341 Do we allow either or both of these extensions? 
    342  
    343   * '''Options:''' yes,no,module,wg2,undecided 
    344   * '''Preferences:''' undecided 
    345  
    346475=== 39 syntax-error === 
    347476 
     
    349478when macros are expanded. 
    350479 
    351 There is a definition in JRM's Syntax-Rules Primer using syntax-rules, 
    352 but it relies on the syntax-rules implementation reporting an 
    353 unmatchable pattern with a complaint that includes the pattern. 
    354  
    355   * '''Options:''' yes,no,module,wg2,undecided 
    356   * '''Preferences:''' yes,module 
    357  
    358 Decent error reporting isn't hard to implement, and makes macro debugging much easier. 
     480  * '''Options:''' yes,no,module,wg2,undecided 
     481  * '''Preferences:''' yes,module,wg2 
     482 
     483I think it's good to distinguish a syntax error from a coding error in the macro itself, which should call `error`. 
    359484 
    360485=== 5 syntax-rules === 
     
    389514  * '''Options:''' yes,no,wg2,undecided 
    390515  * '''Preferences:''' yes 
    391  
    392 For consistency with define. 
    393516 
    394517== WG1 - Numerics == 
     
    404527  * '''Preferences:''' yes 
    405528 
    406 I've encountered many quantities that seem approximately infinite in my daily life, and being able to model these in software would be useful. 
    407  
    408 === 21 limited type arithmetic === 
    409  
    410 R6RS provides libraries for limited type arithmetic 
    411 on fixnums only and flonums only.  Do we want these? 
    412  
    413   * '''Options:''' yes,no,module,wg2,undecided 
    414   * '''Preferences:''' no,module 
    415  
    416 === 22 mantissa widths === 
    417  
    418 R6RS introduced the concept of mantissa widths 
    419 as an alternative to the R5RS #s in numbers. 
    420 Do we want either or both of these? 
    421  
    422   * '''Options:''' r5rs,r6rs,both,no,wg2,undecided 
    423   * '''Preferences:''' undecided 
    424  
    425529== WG1 - Reader Syntax == 
    426  
    427 === 11 case-sensitivity === 
    428  
    429 Does the reader fold case by default, and if so how? 
    430  
    431 Yes to fold-case (R5RS) no to preserve case (R6RS), additional votes 
    432 to come later from specific proposals. 
    433  
    434   * '''Options:''' yes,no,undecided 
    435   * '''Preferences:''' no 
    436  
    437 Case folding is hard to implement in the presence of Unicode, and having had a long history of C programming, I instinctively preserve case myself. People should be discouraged from defining symbols that differ only in case, but only by warnings that it may confuse other readers. 
    438530 
    439531=== 15 #\foo character names === 
     
    456548  * '''Preferences:''' no 
    457549 
    458 I think there's other things we could do with [], but experimentation is needed before proposing anything. 
    459  
    460550=== 14 alternate comment syntax === 
    461551 
     
    467557  * '''Preferences:''' both 
    468558 
    469 They're simple parser extensions, and both very useful, and quite widely implemented anyway. 
    470  
    471559=== 16 symbol escapes === 
    472  
    473 [This ticket was originally about string escapes, but commenters have 
    474 been talking about symbol escapes instead.] 
    475560 
    476561R6RS provides character escapes in symbols of the form `\xnnnn;`, 
     
    478563also allow |...| to escape a whole symbol or a part of one? 
    479564 
    480   * '''Options:''' yes,no,module,wg2,undecided 
    481   * '''Preferences:''' yes 
     565  * '''Options:''' numeric,quoted,both,no,wg2,undecided 
     566  * '''Preferences:''' both 
    482567 
    483568I think that since string->symbol takes any string, any symbol should be representable in sexprs. 
     
    491576 
    492577  * '''Options:''' numeric,mnemonic,both,no,wg2,undecided 
    493   * '''Preferences:''' both,numeric 
     578  * '''Preferences:''' both, numeric 
     579 
    494580 
    495581The numeric escapes are very useful (for writing non-ascii literals in ascii sources, for a start); the mnemonics are cheap to implement and are useful. 
     
    509595Keep explicit dependencies on supporting the entire Unicode stack out of WG1, IMHO 
    510596 
     597 
    511598=== 26 string normalization === 
    512599 
     
    521608Keep explicit dependencies on supporting the entire Unicode stack out of WG1, IMHO 
    522609 
     610 
    523611=== 27 string-ref/set! access time === 
    524612 
     
    545633John Cowan knows his Unicode. 
    546634 
    547 == Working Group 1 == 
    548  
    549 === 1 Which VCS do we use? === 
    550  
    551 There is the question of the right VCS to use. I prefer 
    552 Monotone. Currently we are having an email vote on the list. I have 
    553 entered this ticket to play with the Trac ticketing system. We can 
    554 finalize the ticket once we have chosen a VCS. 
    555  
    556   * '''Options:''' bzr,darcs,git,hg,monotone,svn,undecided 
    557   * '''Preferences:''' git,hg,svn