Common interval literals (was comments on the comments...)
John, Vincent,
In ideal world Section 9.4 would contain a grammar for a common interval,
and Section 12.11 would extend it.
The current state 9.4 is due to a rush in October 2013, see two emails below.
Nevertheless, I can be blamed should fix later it 2013 or 2014 .
> (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?
Interval literals are used as arguments of a operation. "Context" is the operation.
s denotes a decorated interval when s is argument of decorated version of textToInterval(s).
s denotes a bare interval when s is argument of bare version of textToInterval(s).
However, if *Demoting* is considered risky argument of the bare version
could be restricted to bareIntvlLiteral .
> (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".
Ok.
> 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.
specialIntvl has sense in all flavours. It is sufficient to remove "?" alternative from "radius" rule.
> But is it too much of a change at this late stage? Comments ASAP please.
I can't decide this.
If officers decide to approve these changes, I can assist.
-Dima
=== Dmitry Nadezhin wrote October 3, 2013: ====
Vincent,
I'm not sure the syntax in the common part of the standard
can be exactly the same as it is now.
Decoration systems are flavor-specifix.
Set-based flavour has "[NaI]" form and "_trv", "_def", "_dac", "_com" decoration suffixes.
Modal flavor has decorations "_ein", "_dac", "_def", "_gap", "_ndf".
Probably, modal flavor doesn't need the "[NaI]" form.
The "-inf" and "+inf" number literals and unbounded uncertain forms "1??u"
are not necessary for common intervals.
Kaucher/modal flavours need to extend flavor indepent syntax
with negative radius and with "l > u" permission:
"[11,7]"
"9?-2".
Hence it is not so simple to move subsection section 12.11 into Chapter 1.
It will be necessary to split it into flavor-independed and set-based specific parts
whith links from set-based to flavor-independent. I'm still in doubts.
-Dima
====
=== John Pryce wrote October 3, 2013: ====
On 2013 Oct 3, at 05:11, Dmitry Nadezhin wrote:
> Hence it is not so simple to move subsection section 12.11 into Chapter 1.
> It will be necessary to split it into flavor-independed and set-based specific parts
> whith links from set-based to flavor-independent. I'm still in doubts.
I prefer to keep away from this. Maybe the new §9 in Ch 1 could say all flavors *should* have interval literals as compatible as possible to the set-based ones, and leave it at that.
John