Re: Defining "common interval literal"
Vincent
On 31 Mar 2015, at 15:33, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> On 2015-03-31 10:33:25 +0000, John Pryce wrote:
>> On 26 Mar 2015, at 16:02, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
>>> In this new text, §9.7.1 "Overview":
>>>
>>> | An ***all-flavor*** literal is one that has the same value (modulo
>>> | the embedding map if it is an interval literal) in all flavors.
>>>
>>> is ambiguous. What does "in all flavors" mean? All flavors defined
>>> in this standard (but this consists only of the set-based flavor)?
>>> All flavors supported by the implementation (but such literals would
>>> depend on the implementation)? According to the next sentences, I
>>> suppose that "in all flavors" means "in all potential flavors" or,
>>> said otherwise, "in all flavors allowed by this standard".
>>
>> I see what you mean. But since 7.1 says "A flavor is an interval
>> model that conforms to the core specification described below" isn't
>> it correct as written? Yes, one could say "... in all potential
>> flavors", but that doesn't read as good standardese to me.
>
> The problem is on the "all", which can be interpreted in different
> ways. Normally things that don't exist yet are not part of the "all".
> So, "all flavors" should currently mean "the set-based flavor".
>
> For instance, if I say "all members of the stds-1788 list", this
> doesn't include future members.
>
>>> | An all-flavor interval literal denotes a common interval, which
>>> | if decorated has the decoration com.
>>>
>>> is in contradiction with the previous sentence if the only flavor
>>> is the set-based one, because only this one is currently defined
>>> in P1788. But it is OK with "in all potential flavors".
>>
>> Hmm. Once "all-flavor" has been declared as a technical term, IMHO
>> this ceases to be a contradiction.
>
> But what this technical term means is not clear.
1. OK, I guess the text as written doesn't properly distinguish the _definition_ of "all-flavor" literals from the standard's _requirement_ on them.
2. It also should be made clearer that literals "of the flavor" are required to be such by a flavor.
3. "It shall document such extensions and restrictions" lower down should be down to the flavor to require; the standard should, however, say a flavor may permit such things.
4. The notion of "common interval literal" is no longer used anywhere so I removed it.
As a result I now have:
This subclause defines *all-flavor* number and interval literals. An all-
flavor literal shall have the value defined here (modulo the embedding
map if it is an interval literal) in all flavors. An all-flavor interval
literal denotes a common interval; if decorated it has the decoration
com.
A flavor may define a set of literals, including the all-flavor literals,
that shall have the same value in each implementation of the flavor;
these are called literals *of the flavor*. (E.g., inf and [1,inf] are
literals of the set-based flavor that shall have the values +oo and [1, +oo]
in each implementation.)
An implementation may support an extended form of literals, e.g., using
number literals in the syntax of the host language of the implementation.
It may restrict the support of literals at Level 2, by relaxing
conversion accuracy of hard cases: rational number literals, long
strings, etc. What extensions and restrictions of this kind are permitted
is flavor-defined.
Will that do? As I said, I do not think the standard should talk of "potential flavor" any more than it talks of "potential implementation". The distinction Vincent has drawn should be expressed by correct use of "shall" language versus "is" language, which I think I have now done.
Vincent, thanks for holding my feet to the fire. Please continue to do so.
John Pryce