Re: textToIntevsal(s) and exceptions
Vincent & all
Please comment on the proposed shortened constructor text below between === lines.
On 19 Mar 2015, at 18:05, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> On 2015-03-18 11:22:09 +0000, John Pryce wrote:
>> ...
>> 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.
>
> I'm not opposed, but I'm not sure that this is really necessary
> in practice. A "should" may be better since we are not sure about
> the usefulness and the consequences.
>
>> - *Permit* other forms, such as "nai".
>
> Yes.
>
>> 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.
>
> I think that it should only be a recommendation on flavors.
>
> BTW, in an implementation supporting only common intervals, demotion
> doesn't seem to be a problem since there's no ambiguity.
I guess you are advising that we should be as un-prescriptive as possible on things we don't have enough experience to be prescriptive about. That seems wise.
Following this advice I removed the "each bare constructor shall have a corresponding decorated constructor" text entirely because it's hard to define "corresponding" briefly. Instead, after the definitions of the bare numsToInterval & textToInterval I've put:
===============
1 These constructors shall have decorated versions as follows.
2 – The decorated operation numsToInterval(l,u) has value newDec(x) if the bare operation has value x.
3 – The decorated operation textToInterval(s) has:
4 – value xd if s is a decorated interval literal of the flavor with value xd;
5 – value newDec(x) if s is a bare interval literal of the flavor with value x.
6 A flavor may define extensions of these constructors and/or provide other constructors.
7 ...[Example about Kaucher improper interval, + giving constructor an extra argument like Marco's]
...
8 An implementation may relax at Level 2 the accuracy mode ...
===============
Points:
- This is only prescriptive about the two standard constructors
numsToInterval & textToInterval.
- It is short.
- It drops the "Otherwise it has no [common] value" stuff.
- It explicitly includes promotion of the kind Dmitry put in (line 5).
I think it would look weird not to include it.
- In line 4 it refers to the sx_sd syntax, hence this is required in all
flavors.
>> 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?
>
> Do you have an example?
No, I am hoping you, Dmitry or Marco can provide some. I was thinking, suppose in C/C++ one has code like
string s = "[1,2]";
decoratedInterval x;
x = textToInterval(s);
and textToInterval *doesn't* implement line 5 in my text above.
Is there any mechanism in the language to make it try *bare* textToInterval, after *decorated* textToInterval sees s is not a decorated literal, and then apply newDec?
Now I think about it, I guess the answer must be No, except by explicitly coding it into decorated textToInterval.
>> 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).
>
> Yes, probably.
My text above follows that, just for these 2 standard constructors.
>> 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?
>
> Isn't it a consequence of newDec(x)? I mean that if d = newDec(x),
> then x_d must be a permitted combination.
Good point. Yes.
John Pryce