Motion 46: NO
I vote NO on Motion 46 (Interval literals).
The text contains various ambiguities about literals of host language
and locales. In particular:
langNumLit {number literal of host language}
For instance, if the host language is C, what would a number literal be?
A number literal in a C source (the C standard says "integer constant"
and "floating constant")? An input of strtod(), which is the numeric
version of what text2interval is for intervals? This is different as
strtod() is sensitive to locales concerning the decimal-point character
and also case sensitiveness I assume.
Now, are interval literals intended to be sensitive to locales, at least
in some contexts like in C?
What if in the host language, the decimal-point character is a comma ","
(i.e. the same character as the number separator in infSupIntvl), like
for strtod() in some European locales such as fr_FR? This leads to an
ambiguity as the comma would be used for two different purposes.
Moreover, in the second example, about C/C++, I don't think that it is a
good idea to accept floating-suffixes as said in "This is ignored within
an interval literal: 1.2345 and 1.2345f both denote the mathematical
number 1.2345", since in C/C++, 1.2345f only means a float number, which
is mathematically different from the decimal value 1.2345. Why would a
user put a floating-suffix for something that is not a float number?
Accepting floating-suffixes would lead to confusion. Note that these
suffixes make sense only in a source; they are not accepted by strtod(),
where they are regarded as an error.
I think that the standard should fully specify the format of interval
literals or specify nothing. If specification is provided, it should
have a note saying that for case sensitiveness, concepts like locales
are ignored. An implementation may provide functions that accept other
formats and/or take locales into account, but these functions are out
of the scope of this standard.
Other minor remarks:
Is it intended to accept "[empty]" but not "[ empty ]" or more generally
"[" {sp} "empty" {sp} "]"? Ditto for "[entire]".
The term "Constants" for "[empty]" and "[entire]" is rather inadequate
since "[1]" is also a constant. I would say "Special intervals".
Concerning the uncertain form:
* It is said that r is a non-negative decimal integer literal. Is it
intended to allow 0?
* This isn't really important, but I would accept any case for letters,
i.e. "d", "u" and "e" used here, for consistency with the other parts.
* In the examples, I would add:
-10?u [-10,-9.5]
to make sure ulp is well-understood on powers of the radix and that
direction characters are also well-understood on negative numbers.
In the "anycase" example, if locales are chosen to be ignored, it may
be better to use: anycase("ai") matches any of "ai", "Ai", "aI", "AI"
(see discussion about the dotless "i" and "I" with dot in Turkish).
For decorated intervals, I think that connectChar should be specified
(see above about full specification). And shouldn't decorationLit be
case-insensitive?
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)