Re: comments on the comments...
Vincent
You raise substantive questions about 9.4 "Constructors".
See my responses below.
On 17 Feb 2015, at 14:07, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> On 2015-02-16 22:52:10 +0000, John Pryce wrote:
>> On 10 Feb 2015, at 15:53, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
>>> I17: Since a sentence about extension is added as a clarification,
>>> I'm wondering whether a common value is allowed as an extension or
>>> only non-common values are allowed.
>>
>> Have you any examples in mind? Have you an opinion on what should be
>> expicitly allowed, or forbidden?
>
> The more I re-read it, the more I'm confused! Before answering the
> question...
>
> First, there are two textToInterval(s) constructors: a bare one and
> a decorated one. In the lines 7-9, it seems to be the bare one since
> the decorated one is mentioned below, and also because of "its value
> is the common bare interval x". But I'm wondering why the condition
> is "If s is a valid interval literal *with decorated value x_com*
> in the set-based flavor". So, if I understand correctly, despite
> textToInterval(s) is here a bare interval constructor, the string s
> is interpreted as a decorated interval. And I suppose that if the
> decoration part is "com", then the interval part must be a common
> value; and in this case, the item says that the textToInterval(s)
> value is this interval part.
>
> This is how I understand this text.
This is how I understand it too, but I agree with you it could be explained better.
> Then I have several remarks.
>
> What about strings like "[0,+Inf]_com"? Are they necessarily regarded
> as invalid or is an extension allowed to regard them as valid.
As I read it, an extension is not allowed to regard them as valid.
> What if one has a common value at Level 1, but an overflow at Level 2?
> I suppose that Clause 9.4 is a Level 1 specification, but this is not
> explicit (it gives references to both Level 1 and Level 2).
It is certainly intended to be a Level 1 specification.
> What if the decorated value is [0,1]_def? Since the decoration is not
> "com", one would be in the "Otherwise, it has no common value." case.
> However the bare interval value would be [0,1], which is normally a
> common value. This is the main problem I have with the text.
I agree - it seems we have made a dog's breakfast (as we say over here) of this piece of text. I think it goes back to when Dmitry rewrote the spec of interval literals. I don't recall whether he then revised 9.4, or I did. But it makes a "reference paper-chase" that is way too complicated.
AFAICS the 9.4 text
(*) "If s is a valid interval literal with decorated value x_com in the set-based flavor, see 10.5.1, 12.11"
is just intended to say
(**) "If s denotes a common interval"
i.e., a closed bounded nonempty interval. (And forget "closed", as the value of a valid interval literal is always closed.) To mention the com decoration at all in (*) seems a red herring to me.
So I make these points, which may not be quite accurate as I'm tired from two days teaching in Cardiff
(1) Why not just say (**), referring to a grammar for the purpose? See below.
(2) However, there is an inherent defect in 9.4 referring to the set-based flavor. This results from both flavors and the syntax of literals being revised late in the project, and some interactions between them not being noticed.
P1788 specifies a constructor textToInterval(s) that exists in all flavors. Logically, the set of valid (see 12.11.1) s that define a common-interval value, and their syntax and semantics, should be flavor-independent. There may be other s outside this set, that are valid in a given flavor -- as there are in the set-based flavor, e.g. "[0,+Inf]".
(3) The trouble with (*) is related to 12.11.5 line 1:
(+) "A decorated interval literal may denote either a bare
or a decorated interval value depending on context."
This is Dmitry's idea, and I start to regret it. For simplicity:
- Promoting a bare interval literal to decorated, 12.11.5 b),
is probably OK but I would be happy to drop it.
- *Demoting* a decorated literal to bare, as in (+), seems a
risky idea to me and I would prefer to drop it.
Actually, where in the standard are "contexts" specified, that make literal denote one thing or the other?
(4) How much should we prescribe about *decorated* interval syntax in an arbitrary flavor? I can't see anything wrong with insisting that it shall be
{bareIntvlLiteral} "_" {decorationLit}
as at present. And that decorationLit shall include "com".
Because of the above points there seems a strong case for the following.
(a) Define a flavor-independent grammar for portable *common* interval literals.
(b) Place it in Part 1 (flavor-independent stuff), presumably within 9.4.
Then we can, if we think fit, make more precise the 9.4 sentence "A flavor may extend the functionality of these constructors and/or provide other bare interval constructors, as appropriate to the flavor".
My suggestion for (a) is that it should be as in Table 12.2 but omitting empty intervals, unbounded intervals and uncertain form. So I think one omits the grammar elements
infNumLit
dir
radius
uncertIntvl
emptyIntvl
entireIntvl
specialIntvl
and all references to them. Then in view of (4) omit NaI, and define
decorationLit "com"
and say a flavor may extend this grammar as appropriate -- as indeed Table 12.2 would then do.
I think this can resolve Vincent's queries. But is it too much of a change at this late stage? Comments ASAP please.
John Pryce