Changes between Initial Version and Version 1 of WG1Ballot7Results

10/01/12 10:00:47 (5 years ago)

adding seventh ballot results


  • WG1Ballot7Results

    v1 v1  
     1= Notes about Results = 
     3See [wiki:WG1BallotExplanation WG1BallotExplanation]. 
     5= WG1 Ballot Items To Finalize By Sep. 30 = 
     7== WG1 - Core == 
     9=== #121 The semantics of expt for zero bases has been refined === 
     11The R5RS definition of expt is: 
     14 -- procedure: expt z1 z2 
     15     Returns Z1 raised to the power Z2.  For z_1 ~= 0 
     17                          z_1^z_2 = e^z_2 log z_1 
     19     0^z is 1 if z = 0 and 0 otherwise. 
     22however exponents with negative real parts are undefined. 
     23R6RS attempted to clarify this with: 
     26     0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive. 
     27     For other cases in which the first argument is zero, either 
     28     an error is signalled or an unspecified number is returned. 
     31(Ignore the change in exactness, which was strictly editorial 
     32and the examples clarify that the rules ignore exactness.) 
     34This is unique in all the reports of a result either 
     35signalling an error or returning a value.  The motivation 
     36for this was because R6RS consistently removed uses of the 
     37"is an error" terminology which would more naturally fit 
     38this situation. 
     40An alternative, `r5rs-error`, is to restore the "is an error" 
     41text since we are not avoiding this in R7RS: 
     44     The value of 0^z is 1 if (zero? z), 0 if (real-part z) 
     45     is positive, and an error otherwise.  Similarly for 0.0^z, 
     46     with inexact results. 
     49The `/real` variant restricts the domain for the zero 
     50base exception to the real numbers.  This is because 
     510^z^ is mathematically undefined for non-real z, and 
     52implementations do not agree on the result. 
     54  * '''Options:''' r5rs, r5rs-error, r5rs-error/real, r6rs, r6rs/real, undecided 
     55  * '''Default:''' r6rs 
     56  * '''Voters:'''  
     57    * [wiki:WG1BallotCowan Cowan]: r5rs-error, r5rs-error/real, r5rs 
     58    * [wiki:WG1BallotGanz Ganz]: r5rs-error, r5rs-error/real 
     59    * [wiki:WG1BallotGleckler Gleckler]: r5rs-error/real, r5rs-error, r5rs, r6rs/real, r6rs 
     60    * [wiki:WG1BallotHsu Hsu]: r6rs, r5rs-error, r5rs 
     61    * [wiki:WG1BallotMedernach Medernach]: r5rs-error, r5rs, undecided, r5rs-error/real, r6rs, r6rs/real 
     62    * [wiki:WG1BallotShinn Shinn]: r5rs-error/real, r5rs-error, r5rs, r6rs/real, r6rs 
     63    * [wiki:WG1BallotSnellPym SnellPym]: r5rs-error, r5rs, r6rs 
     64  * '''Results:''' '''r5rs-error''', r5rs-error/real, r5rs, r6rs, r6rs/real, undecided 
     65  * '''Ratios:''' 5:2, 7:0, 6:1, 7:0, 7:0 
     66  * '''Rationales:''' 
     68 `Cowan`:: 
     69  I agree that the R6RS rule makes no sense in an R7RS context. However, it's worth saying explicitly that the oddball zero cases are errors. 
     70 `Ganz`:: 
     71  This seems consistent with #367. According to Wikipedia, for pos real b, b^c^ = e^cln(b)^ (the parens may be missing in the R5RS snippet?). The zero base, non-real exponent case can be defined to return nans and we should not preclude that. 
     72 `Gleckler`:: 
     73  R7RS isn't making the is-an-error change. I'm choosing "/real" over non-"/real" because there isn't enough agreement to support the latter. 
     74 `Medernach`:: 
     75  As I understand the above text is just false: 0^0^ and 0.0^0.0^ are mathematicaly undefined, this is because it is not continuous there. Just take x^(-1/log(x))^, when x -> 0 it is equal (and therefore converges) to 1/e instead of 1 ! Provided this is changed I prefer the openness of r5rs-error. Bradley's argument convinces me to retain 0^0^=1 (i.e. only if we have an exact 0 as exponent) as a practical convention. 
     76 `Shinn`:: 
     77  The entire rationale for R6RS not using this option doesn't apply to R7RS. 
     78 `SnellPym`:: 
     79  The R6RS approach isn't applicable, and I prefer explicit errors. 
     81=== #472 clarify semantics of non-library library declarations === 
     83In items #91, #148 and #150 we voted to allow the 
     84use of `include`, `include-ci` and `cond-expand` 
     85at the "top-level" respectively, but there remains 
     86some confusion as to their semantics. 
     88Here "top-level" refers to repl and program body 
     89top-levels, but not library bodies. 
     91One interpretation is that these behave like library 
     92declarations, and can expand into `import` forms. 
     93In this case, for a purely static implementation of 
     94R7RS libraries, they must first be statically scanned 
     95from all top-level forms.  They cannot be used 
     96outside the top-level, and are not even available 
     97as bindings otherwise.  This is the `declaration` 
     100Another interpretation is that they are just normal 
     101macros with the obvious definitions (cond-expand 
     102in terms of the output of the `features` macro), 
     103are available in the `(scheme base)` library, and 
     104consequently can't be used to expand into `import` 
     105since imports have already been resolved.  This is 
     106the `syntax` proposal. 
     108Alternately, we could provide `both`.  If you think 
     109this is all too confusing you could also vote `remove`, 
     110to drop these extensions. 
     112  * '''Options:''' declaration, syntax, both, remove 
     113  * '''Default:'''  
     114  * '''Voters:'''  
     115    * [wiki:WG1BallotCowan Cowan]: declaration, both, syntax, remove 
     116    * [wiki:WG1BallotGanz Ganz]: syntax, remove 
     117    * [wiki:WG1BallotGleckler Gleckler]: remove, syntax, declaration 
     118    * [wiki:WG1BallotHsu Hsu]: syntax, remove, both, declaration 
     119    * [wiki:WG1BallotMedernach Medernach]: syntax, remove, declaration, both 
     120    * [wiki:WG1BallotShinn Shinn]: remove, syntax, both, declaration 
     121    * [wiki:WG1BallotSnellPym SnellPym]: declaration, syntax, both, remove 
     122  * '''Results:''' '''syntax''', remove, declaration, both 
     123  * '''Ratios:''' 5:2, 5:2, 6:1 
     124  * '''Rationales:''' 
     126 `Cowan`:: 
     127  `Declaration` is the option that makes sense to me, ''without'' however permitting declarations in included files (they are currently forbidden). I see no reason in these cases to make a distinction between library bodies on the one hand and programs and REPLs on the other. The `syntax` option allows them to be used in random nested places, which I consider to be unnecessary. 
     128 `Ganz`:: 
     129  I don't like the idea of forms being "inherently" top-level only. 
     130 `Gleckler`:: 
     131  There's just too much confusion in this area. 
     132 `Hsu`:: 
     133  These are common and useful forms, but having them as a separate declaration form, especially for `include` and the like, is very confusing IMO, especially for implementations that will choose to provide a syntactic `include` nonetheless. 
     134 `Shinn`:: 
     135  With the confusion I'd just as soon remove these. If we're going to have it, it's more useful as syntax (as the original commenter wanted), and it encourages better encapsulation to force declarations into libraries. 
     136 `SnellPym`:: 
     137  "declaration" seems the simplest. "both" seems the most complex. "remove" seems to be throwing the baby out with the bathwater. 
     139=== #473 library declaration locations in top-level === 
     141R6RS allows only a single library declaration, `import`, 
     142at the beginning of a program body, and this must 
     143contain all imported libraries. 
     145Pending the result of ticket #472 we may also allow 
     146`include(-ci)` and `cond-expand` to expand into 
     147imports, and so the single form restriction would not 
     148make sense.  However, it would be reasonable to 
     149restrict all library declarations to the beginning of 
     150a program - the first non-declaration would begin 
     151the real body.  This is the `beginning-only` option. 
     153The advantage of the `r6rs` proposal is that it would 
     154not require any changes in existing R6RS program 
     155loading implementations to support.  If the result of 
     156ticket #472 indicates multiple declaration types are 
     157available this option would automatically become 
     158invalid, so you don't need to vote against it on those 
     161The advantage of the `beginning-only` option is 
     162that it becomes possible to statically determine 
     163all program imports without expansion, which was 
     164the primary motivation of a static library system. 
     166The final alternative is `any-top-level`, which 
     167allows these forms anywhere at the top-level, 
     168possibly interspersed with definitions.  The advantage 
     169of this is that you can cut&paste repl sessions 
     170(for which interspersed imports are always allowed) 
     171as a program.  The disadvantage is that programs 
     172can no longer be resolved separately from expansion. 
     174  * '''Options:''' r6rs, beginning-only, any-top-level 
     175  * '''Default:'''  
     176  * '''Voters:'''  
     177    * [wiki:WG1BallotCowan Cowan]: beginning-only, any-top-level, r6rs 
     178    * [wiki:WG1BallotGanz Ganz]: any-top-level, beginning-only 
     179    * [wiki:WG1BallotGleckler Gleckler]: r6rs, beginning-only 
     180    * [wiki:WG1BallotHsu Hsu]: any-top-level, beginning-only 
     181    * [wiki:WG1BallotMedernach Medernach]: beginning-only, r6rs, any-top-level 
     182    * [wiki:WG1BallotShinn Shinn]: r6rs, beginning-only, any-top-level 
     183    * [wiki:WG1BallotSnellPym SnellPym]: beginning-only, any-top-level, r6rs 
     184  * '''Results:''' '''beginning-only''', any-top-level, r6rs 
     185  * '''Ratios:''' 5:2, 5:2 
     186  * '''Rationales:''' 
     188 `Cowan`:: 
     189  Note that this is about programs only, not REPLs or library bodies. I really, really dislike both `any-top-level` and `beginning-only`. The first is too flexible, the second, not flexible enough. Very reluctantly I choose `beginning-only` because it preserves static analysis. I see no benefit to the `r6rs` option at all, given that R6RS systems will have to provide additional support for R7RS library syntax anyway. 
     190 `Ganz`:: 
     191  I think that import should generally act like a multi-define, and so should be usable like a top-level define. The question of redefining import is a separate one, and should be discussed separately. 
     192 `Gleckler`:: 
     193  As long as we're only restricting what the standard supports but are not restricting how implementations may extend their own implementations, I'm fine with this. In that case, preserving R6RS compatibility is a good idea. 
     194 `Shinn`:: 
     195  If applicable we should strive for at least this much compatibility with R6RS. Otherwise, we definitely should not allow `any-top-level` which defeats the purpose of having a static library system. 
     196 `SnellPym`:: 
     197  beginning-only is a conservative minimum to require; implementations might choose to be more flexible without becoming incompatible. 
     199=== #405 Retract language requiring force to accept non-promises === 
     201#405 lumped together several issues, one of which was a requirement 
     202(as opposed to an option) to make `force` applied to a non-promise 
     203return its argument, as opposed to it being an error.  Thus, it would 
     204require `(force 2) => 2`.  However, R6RS 
     205requires `(force 2)` to signal an error, and many non-R6RS Schemes also 
     206signal an error (see ForceNonPromise for details).  These facts were not 
     207considered at the time. 
     209Vote `retain` to retain this requirement, or `retract` to retract it 
     210and leave the result of `(force 2)` implementation-dependent. 
     212  * '''Options:''' retain, retract 
     213  * '''Default:''' retain 
     214  * '''Voters:'''  
     215    * [wiki:WG1BallotCowan Cowan]: retract 
     216    * [wiki:WG1BallotGanz Ganz]: retain 
     217    * [wiki:WG1BallotGleckler Gleckler]: retract 
     218    * [wiki:WG1BallotHsu Hsu]: retract 
     219    * [wiki:WG1BallotLucier Lucier]: disjoint 
     220    * [wiki:WG1BallotMedernach Medernach]: retract 
     221    * [wiki:WG1BallotRead Read]: disjoint 
     222    * [wiki:WG1BallotShinn Shinn]: retract 
     223  * '''Results:''' '''retract''', disjoint, retain 
     224  * '''Ratios:''' 5:2, 5:1 
     225  * '''Rationales:''' 
     227 `Cowan`:: 
     228  I can't see forcing all R6RS systems into non-compliance over this small point. 
     229 `Ganz`:: 
     230  If a programmer needs to know what is and is not a suspension before forcing it, suspensions are not that different from thunks (so why bother). It should be possible for a portable program to be lazy (sorry) and not have to worry about whether something is a suspension or not. This requirement does not break any programs, and there is no other reasonable value to return. Also, extending forcing in this way seems consistent with the implicit forcing that occurs on primitive application. 
     231 `Gleckler`:: 
     232  There isn't enough agreement among implementations to impose the new requirement. 
     233 `Shinn`:: 
     234  This was just an oversight when the item was originally proposed - there's no grounds to require this.