Re: Motion 46 -- Vincent's objections
(I changed the subject line because I'm not voting right now; nor were
Ian and John.)
We have to make clear that the term "interval literal" is used in a
non-standard way. We use it as a shorthand for the argument to the
text2interval() operation.
No interval or floating-point standard has any say in what the syntax
of any particular language should be: what we wish to standardize is
the semantics, i.e. the expected behaviour. So we have no say in how
a language supports its literals -- including interval literals for
languages (like Sun Fortran) that support them as first-class types.
This was clearly stated in 754-2008 for example.
What we CAN and SHOULD standardize are interchange formats, i.e. the
behaviour of the text2interval() and interval2text() operations (and
not their actual names, or the syntax of their invocation).
For this purpose, interval2text() should be precise, and text2interval()
permissive, and of course the latter must accept what the former produces.
In a world with widely different conventions it is useful to have the
concept of locale-dependency, but one must also be able to be universally
precise. I don't have much experience with the locale issues of atof(),
say, but I did trip over such issues in the AIX libc implementation, and
I find it troublesome that there is no guaranteed way to recognize a
floating-point literal. I would have preferred if the so-called C-locale
notation was ALWAYS accepted, and others might be accepted too, especially
since there is no conflict with digit-separators which, though possible on
output, are (as far as I recall) NOT accepted on input: 1,234.56 for
example is recognized as 1 (the rest is junk). So in a European locale,
where one would write 1234,56 there should be no ambiguity if 1234.56 is
entered, because 1.234,56 would not be acceptable as equivalent to 1234,56
and would (in the absence of additional C-locale interpretation) be taken
to be 1.
So I think we should define a standard format for text2interval() arguments,
and we could compare them to the C locale for clarity. We would obviously
not refuse a locale-dependent variant -- it is always permissible to provide
additional functions, or perhaps even the same function which ALSO allows
locale-dependent forms, together with whatever might be required to avoid
conflict with the standard syntax.
Turkish locales might have difficulty with Inf vs inf, but I can imagine
worse: what if a locale specifies right-to-left strings? I know that numeric
literals are witten in the same order as for left-to-right scripts, but what
about the order of bounds in the pair that denotes an interval? Is the low
bound the first or the leftmost element?
Getting back to comma vs point. C syntax uses comma for separating elements
of an initializer, among other things. How would that interact with numeric
literals containing a comma? That's why locale has no impact on C literals,
even though it does affect some common library functions.
Michel.
---Sent: 2013-07-19 19:40:04 UTC