| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Vincent, Baker, P1788 My ideas on several points. I label them editorial or technical as we have to do for sponsor ballot comments. ----- (A) [Mainly editorial, slightly technical] On 5 Mar 2015, at 10:17, Vincent Lefevre <vincent@xxxxxxxxxx> wrote: > On 2015-03-04 16:15:30 +0000, John Pryce wrote: >> Comments please on this fairly drastic shortening of §12.11 >> "Interval and number literals". It needs to be read alongside the >> new §9.4, which Dmitry will be revising, or maybe has already. > > I'm wondering whether interval literals should be specified mainly > at Level 1 instead of Level 2. The new §12.11.1 says: "This subclause > extends the specifications of 9.4" but §9.4 in mainly about Level 1, > and when one writes "[1.234e5,Inf]", this first designates a Level 1 > interval. I thought about this. If we change it, I suggest deleting 10.5.1 entirely and moving 12.11 to be a subclause just before 10.5 "Required operations" -- not a sub-sub-clause *of* 10.5. Its references to decorations would then of course be *forward* references, which is one reason I am dubious. Baker, what do you think? ----- (B) [Editorial] A related name/location issue that was raised is that §9 is called "Operations required in all flavors" but the literals in 9.4 are not operations! Do they deserve a clause in Part 1 to themselves? I don't think so, as they are rather minor beside broad topics such as "Flavors", "Decoration system" etc. So maybe rename §9? How about "Operations and related items required in all flavors"? And insert after the first sentence of §9 something like "It also defines interval literals, which are operands of the textToInterval operation." Would that do? ----- (C) [Editorial] Could we move the current 9.6, 9.7, 9.8 in front of current 9.4 Literals and 9.5 Constructors? They are small and rather "lost" at present. ----- (D) [Editorial] The "s" denoting a string in 9.5 and 10.5.8 aren't bold, but those in 9.4 and 12.12.7 and 13 are. I suggest all should be bold. ----- (E) [Technical] We need to sort out the issues Vincent (e.g. 20150311 at 00:34) has identified about constructors in 9.5. This is not intended as criticism of Dmitry, who has done an excellent job. First please see and comment on my latest version of the start of 9.4, attached, which is more explicit about "Common bare/decorated interval literals". (E1) I say in 9.4.1 "A bare interval literal may be promoted to (interpreted as denoting) a decorated interval. The contexts in which this occurs are flavor-defined or language-defined." But I haven't yet changed 9.4.5 "Common decorated interval literals" to match. It still says *all* flavors shall promote. Which shall we do? Personally I prefer making it flavor-defined or language-defined. Even then I ask: why should it be flavor-defined at all? Isn't it more a language issue? If we make it so then a) and b) of 9.4.5 would shorten to just b), which I would amend to something like "A valid bare interval literal sx with value x, an underscore "_", and a decoration string sd with value dx, such that X=x_dx is a valid Level 1 decorated interval of the flavor. The value of the literal is X. The string com shall denote the decoration com in all flavors." Then can the following paragraphs in 9.4.5 "If sx has the bare value x..." and "A common decorated interval literal is..." be removed? (E2) Unlike when it was part of the set-based flavor, 9.4.5 has a double purpose: - Say that in every flavor a *general* decorated interval literal has the form sx_sd where sd is one of a flavor-defined set of strings that are labels for the decorations. Maybe require sd be alphanumeric (or even alphabetic)? - Define the *common* decorated interval literals. So should 9.4.5 be split in two? (E3) 9.5. As Vincent says, why should the spec for textToInterval just be about *common* intervals? Can we say something like "The bare operation textToInterval(s) takes a text string s. Its Level 1 value is that of s, if s is a bare interval literal of the flavor, see 9.4.4." (E4) 9.5. Like Vincent I don't like "Otherwise, it has no common value, except for the decorated textToInterval(s) constructor." That looks like a signal of bad design. Is it safe just to delete *all* the "Otherwise, it has no common value..." sentences? (E5) The text about relaxing conversion accuracy (near end of 9.4.1 and end of 9.5) should only be said once. I'm working on these and welcome suggestions ASAP. Current text, "in progress", attached. (Same filename as previous, which please discard.) John Pryce
Attachment:
20150317DmitryJohnCh1Literal.pdf
Description: 20150317DmitryJohnCh1Literal.pdf