Re: textToIntevsal(s) and exceptions
Thanks Marco, good example. This is the sort of thing I was concerned about, but too ignorant to formulate.
I think it's outside 1788's scope to say anything about this but the 1788 Implementer's Web Site that we have been promised (does it exist yet...?) can give advice about such things.
Whatever one tries to forbid, a user can always program something stupid on those lines.
John Pryce
On 23 Mar 2015, at 19:56, Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>> 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.
>>
>> I can give an example with the GNU Octave interval package (version 0.1.4), where “infsup” implements the bare textToInterval and “infsupdec” implements the decorated textToInterval.
>>
>> This implementation automatically promotes bare intervals if the user calls an operations with mixed arguments, i. e. if at least one operand is decorated. Whether this has been a good or bad decision remains to be seen. Demotion does not happen automatically and the user must explicitly call “intervalpart” for that purpose.
>>
>> pkg load interval
>>
>> x = infsup ("[1,2]"); # [1, 2]
>> y = infsupdec ("[1,2]"); # [1, 2]_com (automatic promotion cf. (5))
>> z = infsupdec ("[1,2]_dac"); # [1, 2]_dac
>>
>> y + z # [2, 4]_dac (decorated operation evaluation)
>> y + x # [2, 4]_com (input x became promoted)
>> z + x # [2, 4]_dac (input x became promoted)
>>
>
> In my opinion we should avoid implicit conversion between bare and decorated intervals
> as well as using inheritance...
>
> Example.
>
> two classes:
> interval
> decorated_interval (inherited from interval)
>
> if we have a user function like
>
> interval foo(interval x)
>
> which is only implemented for bare intervals.
>
> In many languages a call of foo with a decorated interval x_d will throw the the decoration d away
> because x_d is an object of decorated_interval which is inherited from interval. Hence x_d is an interval x.
>
> If we additionally have implicit conversion from interval to decorated_interval like in Olivers example
> than the result of this expression
>
> decorated_interval("[1,2]_com") + foo( decorated_interval("[4,5]_def") )
>
> has the decoration com.