Re: Motion P1788/M0051:IntervalLiteralsText: Michel's comments
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