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 | | |
31 | | however exponents with negative real parts are undefined. |
32 | | R6RS attempted to clarify this with: |
| 32 | For this final vote there are three proposals under consideration, |
| 33 | corresponding to the complete forms of each equivalence. Variations |
| 34 | may be proposed and added if a suitable rationale is given. |
| 35 | |
| 36 | The `r5rs` proposal follows R5RS exactly, in the spirit of |
| 37 | mathematical equivalence (assuming exacts and inexacts are different |
| 38 | types to begin with). The advantage of this is it's very simple and |
| 39 | it appeals to idealists - people who want to pretend that they are |
| 40 | computing real mathematical values without such thing as NaNs or |
| 41 | negative zeros. The disadvantage of this is, as with most things that |
| 42 | appeal to idealists, it does not match reality. Our computers use |
| 43 | crude hacks for efficiency, and even if someone manages to build an |
| 44 | ideal Scheme, it will likely be impractical and most implementations |
| 45 | will continue to use those hacks. Moreover, mathematical equivalence |
| 46 | is already available via the `=` procedure. This is not a practical |
| 47 | equivalence relation for a standard. The text for the true case of |
| 48 | `eqv?` for inexact numbers under `r5rs` is: |
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: |
| 55 | The `r6rs` proposal follows R6RS exactly in the spirit of operational |
| 56 | equivalence (with a small correction to avoid making everything |
| 57 | unspecified via NaN transitivity). The advantages of this is that |
| 58 | it's exactly what you want to distinguish if two values will always |
| 59 | behave the same, for example for compiler optimizations or |
| 60 | memoization. The disadvantage is that the definition is complicated |
| 61 | and difficult to nail down - it doesn't account for non-standard |
| 62 | extensions an implementation may provide which could distinguish |
| 63 | certain new values. The `r6rs` text is: |
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. |
| 76 | Finally, the `representational` proposal is based on the previous |
| 77 | `same-bits` in the spirit of representational equivalence. Two |
| 78 | numbers are `eqv?` if they are represented the same way. This is |
| 79 | potentially finer grained than operational equivalence - it may in |
| 80 | fact make useless distinctions, but it is generally safer to |
| 81 | over-distinguish than to under-distinguish. The `representational` |
| 82 | text is: |
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 |
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 | | |