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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports