Changes between Version 32 and Version 33 of WG1BallotMedernach


Ignore:
Timestamp:
12/02/12 10:57:47 (5 years ago)
Author:
medernac
Comment:

9th Ballot

Legend:

Unmodified
Added
Removed
Modified
  • WG1BallotMedernach

    v32 v33  
    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 Sep. 18 = 
    15  
    161== WG1 - Core == 
    172 
    18 === #121 The semantics of expt for zero bases has been refined === 
     3=== #460 Semantics of `eqv?` === 
    194 
    20 The R5RS definition of expt is: 
     5The semantics of `eqv?` are highly contended, and as a result we are 
     6bringing this up for a third and final vote. 
     7 
     8The earlier votes on #125 (`eqv?` may not return true for procedures) 
     9and #229 (`eqv?` is unspecified for NaNs) were voted on and treated as 
     10orthogonal.  There have been no objections to these, and so the 
     11results still stand.  We're only focusing on the core `eqv?` semantics 
     12for inexact numbers. 
     13 
     14This is fundamentally a tale of three equivalences: mathematical, 
     15operational, and representational. 
    2116 
    2217{{{ 
    23  -- procedure: expt z1 z2 
    24      Returns Z1 raised to the power Z2.  For z_1 ~= 0 
     18Ultra-brief history: 
    2519 
    26                           z_1^z_2 = e^z_2 log z_1 
    27  
    28      0^z is 1 if z = 0 and 0 otherwise. 
     20R2RS was purely mathematical, defining `eqv?` on numbers in terms of 
     21`=`.  R3RS defined a simple operational equivalence by distinguishing 
     22exact and inexact.  This was not a complete operational equivalence 
     23because R3RS already had multiple precisions and implicit NaNs and 
     24signed zeros.  R[45]RS dropped the discussion of operational 
     25equivalence but kept the exactness separate.  R6RS re-introduced the 
     26notion of operational equivalence, this time with a complete definition. 
     27The R7RS 7th draft introduced an incomplete notion of representational 
     28equivalence - two numbers are `eqv?` iff they have the same IEEE-style 
     29representation. 
    2930}}} 
    3031 
    31 however exponents with negative real parts are undefined. 
    32 R6RS attempted to clarify this with: 
     32For this final vote there are three proposals under consideration, 
     33corresponding to the complete forms of each equivalence.  Variations 
     34may be proposed and added if a suitable rationale is given. 
     35 
     36The `r5rs` proposal follows R5RS exactly, in the spirit of 
     37mathematical equivalence (assuming exacts and inexacts are different 
     38types to begin with).  The advantage of this is it's very simple and 
     39it appeals to idealists - people who want to pretend that they are 
     40computing real mathematical values without such thing as NaNs or 
     41negative zeros.  The disadvantage of this is, as with most things that 
     42appeal to idealists, it does not match reality.  Our computers use 
     43crude hacks for efficiency, and even if someone manages to build an 
     44ideal Scheme, it will likely be impractical and most implementations 
     45will continue to use those hacks.  Moreover, mathematical equivalence 
     46is already available via the `=` procedure.  This is not a practical 
     47equivalence relation for a standard.  The text for the true case of 
     48`eqv?` for inexact numbers under `r5rs` is: 
    3349 
    3450{{{ 
    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. 
     51  (3) obj1 and obj2 are both numbers, have the same exactness, and are 
     52  numerically equal (see `=`). 
    3853}}} 
    3954 
    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: 
     55The `r6rs` proposal follows R6RS exactly in the spirit of operational 
     56equivalence (with a small correction to avoid making everything 
     57unspecified via NaN transitivity).  The advantages of this is that 
     58it's exactly what you want to distinguish if two values will always 
     59behave the same, for example for compiler optimizations or 
     60memoization.  The disadvantage is that the definition is complicated 
     61and difficult to nail down - it doesn't account for non-standard 
     62extensions an implementation may provide which could distinguish 
     63certain new values.  The `r6rs` text is: 
    5164 
    5265{{{ 
    53      The value of 0^z is 1 if (zero? z), 0 if (real-part z) 
    54      is positive, and an error otherwise.  Similarly for 0.0^z, 
    55      with inexact results. 
     66  (3.1) obj1 and obj2 are both exact numbers and are numerically 
     67  equal (see `=`) 
     68 
     69  (3.2) obj1 and obj2 are both inexact numbers, are numerically equal 
     70  (see `=`), and yield the same results (in the sense of `eqv?` and 
     71  excluding `+nan.0`) when passed as arguments to any other procedure 
     72  that can be defined as a finite composition of Scheme’s standard 
     73  arithmetic procedures. 
    5674}}} 
    5775 
    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. 
     76Finally, the `representational` proposal is based on the previous 
     77`same-bits` in the spirit of representational equivalence.  Two 
     78numbers are `eqv?` if they are represented the same way.  This is 
     79potentially finer grained than operational equivalence - it may in 
     80fact make useless distinctions, but it is generally safer to 
     81over-distinguish than to under-distinguish.  The `representational` 
     82text is: 
    6283 
    63   * '''Options:''' r5rs, r5rs-error, r5rs-error/real, r6rs, r6rs/real, undecided 
    64   * '''Default:''' r6rs 
    65   * '''Preferences:''' r5rs-error, r5rs, undecided, r5rs-error/real, r6rs, r6rs/real 
     84{{{ 
     85  (3.1) obj1 and obj2 are both exact numbers and are numerically 
     86  equal (see `=`) 
    6687 
    67 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. 
    68 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. 
     88  (3.2) obj1 and obj2 are both numbers of the same composite numeric 
     89  type, whose corresponding fields are all `eqv?` 
     90 
     91    * numbers in the style of the IEEE 754-2008 floating point 
     92      standard are considered composites of their radix, precision, 
     93      maximum exponent, sign, exponent, and significand 
     94 
     95    * non-real complex numbers are composites of their real and 
     96      imaginary parts 
     97}}} 
     98 
     99  * '''References:''' 
     100    * [https://groups.google.com/d/msg/scheme-reports-wg1/BGvDFtD6A1M/5pHmfXHtvEIJ eqv? issues summarized] 
     101    * [https://groups.google.com/d/msg/scheme-reports-wg1/2Nv6oIND8HI/Z2HXPQMNFooJ the history of eqv? on numbers] 
     102    * [http://lists.scheme-reports.org/pipermail/scheme-reports/2012-November/002914.html Weaver's objection] 
     103    * [http://www.math.purdue.edu/~lucier/r7rs-eqv-discuss Lucier on IEEE 754] 
     104  * '''Options:''' r5rs, r6rs, representational 
     105  * '''Default:''' r5rs 
     106  * '''Preferences:''' r6rs, representational, r5rs 
    69107 
    70108 
    71 === #472 clarify semantics of non-library library declarations === 
     109Rationale: IMHO the only sensible choice is operational equivalence, at the end of the day it is all about one implementation being consistent in its choice of equivalence classes. This left an open door for implementation and at the same time avoid inconvenience to users. 
    72110 
    73 In items #91, #148 and #150 we voted to allow the 
    74 use of `include`, `include-ci` and `cond-expand` 
    75 at the "top-level" respectively, but there remains 
    76 some confusion as to their semantics. 
     111'''representational''' is maybe too low-level, I mean the underlying concept here is about equivalence class and I would let implementors freedom/discretion of how they check for it. Again and of course de-composition is the way to go most of the time. I am sure the 2 proposals are not too far from each other. 
    77112 
    78 Here "top-level" refers to repl and program body 
    79 top-levels, but not library bodies. 
     113I suggest therefore that an editorial note may be added to the '''r6rs''' option saying something along the line of that: 
    80114 
    81 One interpretation is that these behave like library 
    82 declarations, and can expand into `import` forms. 
    83 In this case, for a purely static implementation of 
    84 R7RS libraries, they must first be statically scanned 
    85 from all top-level forms.  They cannot be used 
    86 outside the top-level, and are not even available 
    87 as bindings otherwise.  This is the `declaration` 
    88 proposal. 
     115  ''One possible implementation is to check subpart eqv?-eness if it is consistent with equivalence classes wished to be provided by the implementation.'' 
    89116 
    90 Another interpretation is that they are just normal 
    91 macros with the obvious definitions (cond-expand 
    92 in terms of the output of the `features` macro), 
    93 are available in the `(scheme base)` library, and 
    94 consequently can't be used to expand into `import` 
    95 since imports have already been resolved.  This is 
    96 the `syntax` proposal. 
    97117 
    98 Alternately, we could provide `both`.  If you think 
    99 this is all too confusing you could also vote `remove`, 
    100 to drop these extensions. 
    101  
    102   * '''Options:''' declaration, syntax, both, remove 
    103   * '''Default:'''  
    104   * '''Preferences:''' syntax, remove, declaration, both 
    105  
    106 === #473 library declaration locations in top-level === 
    107  
    108 R6RS allows only a single library declaration, `import`, 
    109 at the beginning of a program body, and this must 
    110 contain all imported libraries. 
    111  
    112 Pending the result of ticket #472 we may also allow 
    113 `include(-ci)` and `cond-expand` to expand into 
    114 imports, and so the single form restriction would not 
    115 make sense.  However, it would be reasonable to 
    116 restrict all library declarations to the beginning of 
    117 a program - the first non-declaration would begin 
    118 the real body.  This is the `beginning-only` option. 
    119  
    120 The advantage of the `r6rs` proposal is that it would 
    121 not require any changes in existing R6RS program 
    122 loading implementations to support.  If the result of 
    123 ticket #472 indicates multiple declaration types are 
    124 available this option would automatically become 
    125 invalid, so you don't need to vote against it on those 
    126 grounds. 
    127  
    128 The advantage of the `beginning-only` option is 
    129 that it becomes possible to statically determine 
    130 all program imports without expansion, which was 
    131 the primary motivation of a static library system. 
    132  
    133 The final alternative is `any-top-level`, which 
    134 allows these forms anywhere at the top-level, 
    135 possibly interspersed with definitions.  The advantage 
    136 of this is that you can cut&paste repl sessions 
    137 (for which interspersed imports are always allowed) 
    138 as a program.  The disadvantage is that programs 
    139 can no longer be resolved separately from expansion. 
    140  
    141   * '''Options:''' r6rs, beginning-only, any-top-level 
    142   * '''Default:'''  
    143   * '''Preferences:'''  beginning-only, r6rs, any-top-level 
    144  
    145 === #405 Retract language requiring force to accept non-promises === 
    146  
    147 #405 lumped together several issues, one of which was a requirement 
    148 (as opposed to an option) to make `force` applied to a non-promise 
    149 return its argument, as opposed to it being an error.  Thus, it would 
    150 require `(force 2) => 2`.  However, R6RS 
    151 requires `(force 2)` to signal an error, and many non-R6RS Schemes also 
    152 signal an error (see ForceNonPromise for details).  These facts were not 
    153 considered at the time. 
    154  
    155 Vote `retain` to retain this requirement, or `retract` to retract it 
    156 and leave the result of `(force 2)` implementation-dependent. 
    157  
    158   * '''Options:''' retain, retract 
    159   * '''Default:''' retain 
    160   * '''Preferences:''' retract 
    161