On 2011-05-01, at 16:27, Malcolm Tredinnick wrote:
> Whilst it doesn't have to, an implementation might want to [flag `polar'
> values] for exactness purposes. There's a lot of implementation-specific
> leeway in what they can provide in that area, but both 3@4 and #e3@4 are
> exact and that property is lost when converting to rectangular
> representation. Of course, it's an extremely minor point, since there aren't
> many arithmetical operations you can do with polar forms that preserve
> exactness.and most of the time a real-world app will be using multiples of pi
> for the angle argument, leading immediately into inexact land.
>
> End of the day, though, this is all pretty minor. Even without polar forms in
> the base language, we wouldn't be too deprived. So stuff like that feels a
> bit academic to me providing whatever is in the spec is, well, clearly
> specified.
I agree. I would not like to see anything that forces an implementation to flag
`polar' values, and would consider an implementation that did that strange.
I agree with Malcolm about the need for clear specification. I would therefore
like to suggest saying that
- STRING->NUMBER, and hence READ, produces an exact value from a rectangular
complex literal iff the real and imaginary parts are both exact
- STRING->NUMBER, and hence READ, produces a value from a polar complex
literal whose exactness is implementation-defined
This pretty much constrains that the implementation to using a rectangular
representation internally. If that constraint isn't acceptable, then exactness
from rectangular literals can be implementation-defined as well. I personally
don't much care about these edge cases, but just want to see some kind of
reference made in the Report to their existence.
Also, nowhere in the Report (that I can find) is any statement made that
STRING->NUMBER, READ, and reading program source use the same parser. Perhaps
at the beginning of the number syntax information in ยง7.1.1, there can be a
statement that for any implementation the syntax, semantics, and pragmatics of
these three cases of converting a numeric literal are identical. (I am not here
dealing with whether a user can mutate STRING->NUMBER and thus affect the
behavior of READ; the phrase `the procedure that is the initial value of
STRING->NUMBER' can be used instead, if this is an issue). This statement can
be duplicated in the discussion of READ. A similar statement can be used
regarding WRITE, DISPLAY, and NUMBER->STRING. (And yes, there are language
implementations where these cases don't match, e.g., where you can convert a
string representing a numeric literal to a bignum via a procedure call, but not
write a bignum numeric literal in the source program. In Python, for example,
the only way to insert a decimal number in one's source program is to create a
value at runtime, e.g., decimal.Decimal('3.100').)
-- v
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
