Re: comments on the comments...
Vincent, Dmitry, P1788
On 23 Feb 2015, at 01:01, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> 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.
You have shown my assertion (*) above is shaky. OK, there's a design decision here for xx = textToInterval(s). If we allow "promotion" from bare to decorated, I favour the standard saying
"If xx's bare value is common, and context requires it to be decorated,
the decoration shall be com in all cases."
That is simple to understand. Maybe we already almost say this already, I'll need to check. Any objections to it?
John Pryce