The text of the motion can't be changed during the voting.
This motion is the standard text motion.
I am not sure what is the procedure to ammend fixes to the voted
standard text after the end of motion.
However, most of you comments are reasonable for me.
I shall keep the ammendments and I would apply them if possible.
I think it would be clearer if instead we had
<<<
In this standard, number (and integer) literals are only used
within interval literals.
===
This standard's specification of number (and integer) literals
applies only within interval literals.
I agree.
I think we are still ok however, because the next paragraph says
that "an implementation may support a more general form", which
would indeed permit (but not require) acceptance of hex-format
input without an exponent part (for example, atof() in libc).
I have here my own fix for ammendment period. I would say that
"an implementation shall document the more general form of literals
if it supports it".
A bit below, default locale, I would prefix "e.g." to "C locale".
The syntax of portable literal is concrete and self-consistent.
It doesn't refer to any locale.
So this pharase is a hint how an implementation may construct more
general form.
I agree with "e.g.". If we change this we can change also C to POSIX
"(e.g. POSIX locale)"
because POSIX is more official name of C locale ?
Clause 12.11.3 defines "ulp" quite generally, including for
hexadecimal
formats -- but then 12.11.4 never exploits this. I'm not suggesting
that we require support for uncertain hexadecimal forms, but we
might
point out that such support is conceivable: there could be a "0x"
between the sign and the first digit, and the only question is
whether
any exponent would be introduced with a "p" or an "e": I guess "p".
I don't understand what change do you suggest here. I would keep the
current wording.
For 12.11.4 (b), singleton format: I would add "where x is given",
to make sure "[]" is not interpreted as "[-inf,+inf]" by expanding
a null string x.
A good point! I agree with John's wording:
<<<
A string [ x ], is equivalent to [ x, x ]."
===
A string [ x ], where x is a number literal, is equivalent to [ x, x
]."
or
<<<
A string [ x ], is equivalent to [ x, x ]."
===
A string [ x ], where x is a (finite) number literal, is equivalent
to [ x, x ]."
Yet more changes may happen if we decide that not-an-interval NaI
is not a shortcut for Empty_ill .
There are a few places in the motion text where "NaI=Empty_ill" was
assumed.
"[NaI]" will have decorated interval value, but it it will not have
bare value.
===================
Baker,
What is the procedure of adding friendly ammendments to a standard
text motion ?
Will it be a new standard text motion or a consensus motion or what
?
-Dima
----- Исходное сообщение -----
От: mhack@xxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Среда, 30 Октябрь 2013 г 0:50:51 GMT +04:00 Абу-Даби,
Маскат
Тема: Motion P1788/M0051:IntervalLiteralsText: YES
I vote YES on the text of clause 12.11 (Oct 24 version)
I have some minor comments that might be taken into account
in a final editing phase:
In the 3rd paragraph is the sentence:
In this standard, number (and integer) literals are only used
within interval literals.
The next sentence does clarify the above -- but I think it would
be clearer if instead we had:
This standard's specification of number (and integer) literals
applies only within interval literals.
Subclause (b) of 12.11.2 properly matches the 754-2008 mandatory
hex-format exponent field. I had suggested this (late fix), but
forgot the principle of permissive input vs prescriptive output.
I think we are still ok however, because the next paragraph says
that "an implementation may support a more general form", which
would indeed permit (but not require) acceptance of hex-format
input without an exponent part (for example, atof() in libc).
A bit below, default locale, I would prefix "e.g." to "C locale".
Clause 12.11.3 defines "ulp" quite generally, including for
hexadecimal
formats -- but then 12.11.4 never exploits this. I'm not suggesting
that we require support for uncertain hexadecimal forms, but we
might
point out that such support is conceivable: there could be a "0x"
between the sign and the first digit, and the only question is
whether
any exponent would be introduced with a "p" or an "e": I guess "p".
For 12.11.4 (b), singleton format: I would add "where x is given",
to make sure "[]" is not interpreted as "[-inf,+inf]" by expanding
a null string x.
Michel.
---Sent: 2013-10-29 20:41:54 UTC