Re: comments on the comments...
On 2015-02-20 23:48:57 +0000, John Pryce wrote:
> 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.
I'm not sure. To be able to provide flavor-specific intervals to
textToInterval(s), the flavor needs to define an extension of the
standard grammar. But it may happen that within this extension, some
intervals may be common (at least concerning the interval part). For
instance, consider a flavor that handles intervals that can be open
or semi-open. This flavor may choose to extend the "uncertain" form
to support such intervals, e.g. with:
[3.56?1] -> [3.55,3.57]_com
[3.56?1) -> [3.55,3.57)_dac
(3.56?1] -> (3.55,3.57]_dac
(3.56?1) -> (3.55,3.57)_dac
Or perhaps [3.56?1] should give [3.55,3.57]_dac because the source is
a literal not accepted in all flavors of the implementation, thus not
part of a "common evaluation"? But if you follow this point of view,
you get inconsistencies because a common bare interval gets decorated
with com by default, even if it came from some non-common evaluation.
> (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.
Yes, this means that [0,1]_trv could be demoted to the bare interval
[0,1], then promoted to [0,1]_com. This sounds wrong... well, at least
error-prone.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)