Re: textToIntevsal(s) and exceptions
On 18 Mar 2015, at 10:21, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> On 2015-03-16 20:14:14 +0000, John Pryce wrote:
>> However Vincent's comments make me wonder about extensions, see (*) above:
>>
>> - In 9.4.1 "An implementation may support a more general form of valid interval literals ..."
>> Should the standard put any restrictions on this?
>
> Not in general, but a flavor may recognize some forms as explicitly
> invalid. For the set-based flavor, it would be intervals like [2,-1]
> because it has a recognized form but the condition on l and u is not
> satisfied. I'm not sure whether this is clear (I can't check right
> now).
A big change when moving text from the set-based flavor to the "all flavors" part is that one must answer what I think of as meta-questions: what does the standard require/permit a flavor to require/permit?
Above, I agree with Vincent. Here's another:
What shall be said about the syntax & semantics of decorated interval
literals in *all* flavors?
I think the standard should
- *Require* the sx_sd form to be used by all flavors.
That is, if sx and sd denote interval x and decoration d in the flavor
then sx_sd shall denote x_d, provided this is a valid combination in
the flavor.
- *Permit* other forms, such as "nai".
Please comment on this, also on the promotion bare->decorated question and the reverse, demotion.
I think the standard should forbid demotion, but this may be my prejudice.
For promotion I'm undecided, and wait for advice from language experts.
If it's part of the standard, does that make it different at implementation
level, from making it a consequence of library design and language features,
e.g., by using class inheritance?
If 1788 *permits* promotion, I think it should *require* that a bare interval
literal sx with value x be promoted to x_d with d=newDec(x) (at Level 1).
BTW, do we say anywhere that any interval x in any flavor shall be decoratable?
I.e., there is at least one d such that x_d is a permitted combination?
John Pryce