Changes between Version 65 and Version 66 of WG1BallotCowan


Ignore:
Timestamp:
11/26/12 11:41:16 (5 years ago)
Author:
cowan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotCowan

    v65 v66  
    1 = Instructions = 
     1= Notes about Results = 
    22 
    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 Sep. 18 = 
     3See [wiki:WG1BallotExplanation WG1BallotExplanation]. 
    154 
    165== WG1 - Core == 
    176 
    18 === #121 The semantics of expt for zero bases has been refined === 
     7=== #460 Semantics of `eqv?` === 
    198 
    20 The R5RS definition of expt is: 
     9The semantics of `eqv?` are highly contended, and as a result we are 
     10bringing this up for a third and final vote. 
     11 
     12The earlier votes on #125 (`eqv?` may not return true for procedures) 
     13and #229 (`eqv?` is unspecified for NaNs) were voted on and treated as 
     14orthogonal.  There have been no objections to these, and so the 
     15results still stand.  We're only focusing on the core `eqv?` semantics 
     16for inexact numbers. 
     17 
     18This is fundamentally a tale of three equivalences: mathematical, 
     19operational, and representational. 
    2120 
    2221{{{ 
    23  -- procedure: expt z1 z2 
    24      Returns Z1 raised to the power Z2.  For z_1 ~= 0 
     22Ultra-brief history: 
    2523 
    26                           z_1^z_2 = e^z_2 log z_1 
    27  
    28      0^z is 1 if z = 0 and 0 otherwise. 
     24R2RS was purely mathematical, defining `eqv?` on numbers in terms of 
     25`=`.  R3RS defined a simple operational equivalence by distinguishing 
     26exact and inexact.  This was not a complete operational equivalence 
     27because R3RS already had multiple precisions and implicit NaNs and 
     28signed zeros.  R[45]RS dropped the discussion of operational 
     29equivalence but kept the exactness separate.  R6RS re-introduced the 
     30notion of operational equivalence, this time with a complete definition. 
     31The R7RS 7th draft introduced an incomplete notion of representational 
     32equivalence - two numbers are `eqv?` iff they have the same IEEE-style 
     33representation. 
    2934}}} 
    3035 
    31 however exponents with negative real parts are undefined. 
    32 R6RS attempted to clarify this with: 
     36For this final vote there are three proposals under consideration, 
     37corresponding to the complete forms of each equivalence.  Variations 
     38may be proposed and added if a suitable rationale is given. 
     39 
     40The `r5rs` proposal follows R5RS exactly, in the spirit of 
     41mathematical equivalence (assuming exacts and inexacts are different 
     42types to begin with).  The advantage of this is it's very simple and 
     43it appeals to idealists - people who want to pretend that they are 
     44computing real mathematical values without such thing as NaNs or 
     45negative zeros.  The disadvantage of this is, as with most things that 
     46appeal to idealists, it does not match reality.  Our computers use 
     47crude hacks for efficiency, and even if someone manages to build an 
     48ideal Scheme, it will likely be impractical and most implementations 
     49will continue to use those hacks.  Moreover, mathematical equivalence 
     50is already available vai the `=` procedure.  This is not a practical 
     51equivalence relation for a standard.  The text for the true case of 
     52`eqv?` for inexact numbers under `r5rs` is: 
    3353 
    3454{{{ 
    35      0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive. 
    36      For other cases in which the first argument is zero, either 
    37      an error is signalled or an unspecified number is returned. 
     55  (3) obj1 and obj2 are both numbers, have the same exactness, and are 
     56  numerically equal (see `=`). 
    3857}}} 
    3958 
    40 (Ignore the change in exactness, which was strictly editorial 
    41 and the examples clarify that the rules ignore exactness.) 
    42  
    43 This is unique in all the reports of a result either 
    44 signalling an error or returning a value.  The motivation 
    45 for this was because R6RS consistently removed uses of the 
    46 "is an error" terminology which would more naturally fit 
    47 this situation. 
    48  
    49 An alternative, `r5rs-error`, is to restore the "is an error" 
    50 text since we are not avoiding this in R7RS: 
     59The `r6rs` proposal follows R6RS exactly in the spirit of operational 
     60equivalence (with a small correction to avoid making everything 
     61unspecified via NaN transitivity).  The advantages of this is that 
     62it's exactly what you want to distinguish if two values will always 
     63behave the same, for example for compiler optimizations or 
     64memoization.  The disadvantage is that the definition is complicated 
     65and difficult to nail down - it doesn't account for non-standard 
     66extensions an implementation may provide which could distinguish 
     67certain new values.  The `r6rs` text is: 
    5168 
    5269{{{ 
    53      0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive. 
    54      It is an error for the first argument to be zero in other cases. 
     70  (3.1) obj1 and obj2 are both exact numbers and are numerically 
     71  equal (see `=`) 
    5572 
     73  (3.2) obj1 and obj2 are both inexact numbers, are numerically equal 
     74  (see `=`), and yield the same results (in the sense of `eqv?` and 
     75  excluding `+nan.0`) when passed as arguments to any other procedure 
     76  that can be defined as a finite composition of Scheme’s standard 
     77  arithmetic procedures. 
    5678}}} 
    5779 
    58 The `/real` variant restricts the domain for the zero 
    59 base exception to the real numbers.  This is because 
    60 0^z^ is mathematically undefined for non-real z, and 
    61 implementations do not agree on the result. 
     80Finally, the `representational` proposal is based on the previous 
     81`same-bits` in the spirit of representational equivalence.  Two 
     82numbers are `eqv?` if they are represented the same way.  This is 
     83potentially finer grained than operational equivalence - it may in 
     84fact make useless distinctions, but it is generally safer to 
     85over-distinguish than to under-distinguish.  The `representational` 
     86text is: 
    6287 
    63   * '''Options:''' r5rs, r5rs-error, r5rs-error/real, r6rs, r6rs/real, undecided 
    64   * '''Default:''' r6rs 
    65   * '''Preferences:''' r5rs-error, r5rs-error/real, r5rs 
    66   * '''Rationale:'''  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. 
     88{{{ 
     89  (3.1) obj1 and obj2 are both exact numbers and are numerically 
     90  equal (see `=`) 
    6791 
    68 === #472 clarify semantics of non-library library declarations === 
     92  (3.2) obj1 and obj2 are both numbers of the same composite numeric 
     93  type, whose corresponding fields are all `eqv?` 
    6994 
    70 In items #91, #148 and #150 we voted to allow the 
    71 use of `include`, `include-ci` and `cond-expand` 
    72 at the "top-level" respectively, but there remains 
    73 some confusion as to their semantics. 
     95    * numbers in the style of the IEEE 754-2008 floating point 
     96      standard are considered composites of their radix, precision, 
     97      maximum exponent, sign, exponent, and significand 
    7498 
    75 Here "top-level" refers to repl and program body 
    76 top-levels, but not library bodies. 
     99    * non-real complex numbers are composites of their real and 
     100      imaginary parts 
     101}}} 
    77102 
    78 One interpretation is that these behave like library 
    79 declarations, and can expand into `import` forms. 
    80 In this case, for a purely static implementation of 
    81 R7RS libraries, they must first be statically scanned 
    82 from all top-level forms.  They cannot be used 
    83 outside the top-level, and are not even available 
    84 as bindings otherwise.  This is the `declaration` 
    85 proposal. 
     103  * '''References:''' 
     104    * [https://groups.google.com/d/msg/scheme-reports-wg1/BGvDFtD6A1M/5pHmfXHtvEIJ eqv? issues summarized] 
     105    * [https://groups.google.com/d/msg/scheme-reports-wg1/2Nv6oIND8HI/Z2HXPQMNFooJ the history of eqv? on numbers] 
     106    * [http://lists.scheme-reports.org/pipermail/scheme-reports/2012-November/002914.html Weaver's objection] 
     107    * [http://www.math.purdue.edu/~lucier/r7rs-eqv-discuss Lucier on IEEE 754] 
     108  * '''Options:''' r5rs, r6rs, representational 
     109  * '''Default:''' r5rs 
     110  * '''Preferences:''' r6rs, representational, r5rs 
     111  * '''Rationale:''' I think the `r5rs` choice is Just Wrong as long as IEEE is the dominant representation of inexact numbers: there needs to be a way to distinguish between `0.0` and `-0.0` for memoization and other purposes, as they behave differently for some arithmetic procedures.  For IEEE (always excepting !NaNs, which are implementation-dependent), `r6rs` and `representational` mean the same thing: with only one bit pattern per operationally distinct number, `representational` can't discriminate between them.  In the non-IEEE space, I think the `r6rs` choice is more principled, but I can live with `representational`, though it may end up discriminating between non-IEEE numbers that aren't really different. 
    86112 
    87 Another interpretation is that they are just normal 
    88 macros with the obvious definitions (cond-expand 
    89 in terms of the output of the `features` macro), 
    90 are available in the `(scheme base)` library, and 
    91 consequently can't be used to expand into `import` 
    92 since imports have already been resolved.  This is 
    93 the `syntax` proposal. 
    94  
    95 Alternately, we could provide `both`.  If you think 
    96 this is all too confusing you could also vote `remove`, 
    97 to drop these extensions. 
    98  
    99   * '''Options:''' declaration, syntax, both, remove 
    100   * '''Default:'''  
    101   * '''Preferences:''' declaration, both, syntax, remove 
    102   * '''Rationale:''' `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. 
    103  
    104 === #473 library declaration locations in top-level === 
    105  
    106 R6RS allows only a single library declaration, `import`, 
    107 at the beginning of a program body, and this must 
    108 contain all imported libraries. 
    109  
    110 Pending the result of ticket #472 we may also allow 
    111 `include(-ci)` and `cond-expand` to expand into 
    112 imports, and so the single form restriction would not 
    113 make sense.  However, it would be reasonable to 
    114 restrict all library declarations to the beginning of 
    115 a program - the first non-declaration would begin 
    116 the real body.  This is the `beginning-only` option. 
    117  
    118 The advantage of the `r6rs` proposal is that it would 
    119 not require any changes in existing R6RS program 
    120 loading implementations to support.  If the result of 
    121 ticket #472 indicates multiple declaration types are 
    122 available this option would automatically become 
    123 invalid, so you don't need to vote against it on those 
    124 grounds. 
    125  
    126 The advantage of the `beginning-only` option is 
    127 that it becomes possible to statically determine 
    128 all program imports without expansion, which was 
    129 the primary motivation of a static library system. 
    130  
    131 The final alternative is `any-top-level`, which 
    132 allows these forms anywhere at the top-level, 
    133 possibly interspersed with definitions.  The advantage 
    134 of this is that you can cut&paste repl sessions 
    135 (for which interspersed imports are always allowed) 
    136 as a program.  The disadvantage is that programs 
    137 can no longer be resolved separately from expansion. 
    138  
    139   * '''Options:''' r6rs, beginning-only, any-top-level 
    140   * '''Default:''' 
    141   * '''Preferences:''' beginning-only, any-top-level, r6rs 
    142   * '''Rationale:''' 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. 
    143  
    144 === #405 Retract language requiring force to accept non-promises === 
    145  
    146 #405 lumped together several issues, one of which was a requirement 
    147 (as opposed to an option) to make `force` applied to a non-promise 
    148 return its argument, as opposed to it being an error.  Thus, it would 
    149 require `(force 2) => 2`.  However, R6RS 
    150 requires `(force 2)` to signal an error, and many non-R6RS Schemes also 
    151 signal an error (see ForceNonPromise for details).  These facts were not 
    152 considered at the time. 
    153  
    154 Vote `retain` to retain this requirement, or `retract` to retract it 
    155 and leave the result of `(force 2)` implementation-dependent. 
    156  
    157   * '''Options:''' retain, retract 
    158   * '''Default:''' retain 
    159   * '''Preferences:''' retract 
    160   * '''Rationale:''' I can't see forcing all R6RS systems into non-compliance over this small point.