Re: Common interval literals

[John Pryce <j.d.pryce@xxxxxxxxxx>]

Vincent, Dmitry, P1788

On 23 Feb 2015, at 15:32, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> Dmitry,
> 
> On 2015-02-21 23:54:43 -0800, Dmitry Nadezhin wrote:
>> I tried to adapt "Interval and number literals" from Ch2 to Ch1.
>> Please make a first round of review.
> 
> Here are my comments. Some of them could actually have applied to the
> original text from §12.11 (Interval and number literals).

Yes, I agree. I have taken the liberty of revising Dmitry's latest 
9.4.1, shortening some bits and hopefully answering Vincent's comments.

See attached PDF. Line number references are to this text.
"Done" means I or Dmitry have edited in response to a comment.

> Page 29 line 4 (§9.4.1, first paragraph): "interval literal" is not
> defined. I suppose that it means either a bare interval literal or a
> decorated interval literal, but it is worth a definition. Something
> like:
> 
>  Bare interval literals and decorated interval literals are
>  collectively called interval literals.
Done
> Line 5 (now 7): "if it denotes a finite integer it is an integer literal."
> I would add a comma after "a finite integer".
Done
I added "also", to show integer literal is a particular case of 
number literal, and avoid saying "integer and/or number literal" later.

> Line 6: "The bare interval denoted by a bare interval literal of a
> flavor is its value (as a bare interval literal). Any other string
> has no value in that sense." is unclear. One can guess the meaning,
> but I think that this is not well specified. I wouldn't talk about
> the value of a *string* since it is just the sequence of characters.
> Similarly, line 7, instead of "a string is called valid or invalid
> (as a bare interval literal)", I would say: "a bare interval literal
> is called valid or invalid". What I mean is that one can have:
> 
>  * A string, which is just a sequence of characters.
> 
>  * A bare interval literal, which is a string with some defined
>    interpretation: as a bare interval. A bare interval literal
>    may have a value (= is valid), which is a bare interval, or
>    not (= is invalid).
> 
>  * A decorated interval literal, which is a string with some
>    defined interpretation: as a decorated interval. Similarly,
>    a decorated interval literal may have a value (= is valid),
>    which is a decorated interval, or not (= is invalid).
> 
>  * A number literal, [...]
> 
>  * An integer literal, [...]
It now says a *string* is valid or not *in a context*. 

Please study the example, lines 15-17 to see if we are on the same 
page about what a flavor might allow or forbid. E.g. "might" on 
line 17.

> Line 10: "Bare and decorated interval literals are used as input to
> bare and decorated versions of textToInterval 9.5"
> Text seems to be missing before "9.5".
Done. Also moved to be paragraph 2. 

I don't much like "In this standard, number literals are only used 
within interval literals", can it be said better?

> Line 14: in "conversion of number literals", I don't like the term
> "conversion", since it usually implies a loss of information. Here,
> a number literal has a value (an extended-real number), and there
> is no notion of precision.
Done

Line 24: "Each flavor defines a set of portable... literals".
Should it not be "Each flavor *shall define*..."? This looks like a
requirement the standard puts on each flavor.

Line 26: "support a more general form of valid interval literals"
I removed "valid" as being redundant.

The rest of Vincent's comments of this date seem to be superseded by later discussion. I am studying this.

John Pryce

Attachment: 20150317DmitryJohnCh1Literal.pdf
Description: Adobe PDF document