Re: Draft decoration system for discussion
Vincent
On 12 Dec 2012, at 14:36, Vincent Lefevre wrote:
> You assume here that the threshold t is the same before and after
> Empty has been produced. What I have in mind is that:
>
> 1. xx = Empty can be produced with t = trv in some program block.
> 2. Empty survives across the program block.
> 3. A new program block sets t = dac.
> 4. In this program block, normalInterval(xx) is called.
>
> I don't think §8.8.8 forbids that yet.
That is a VERY good point. I (and others till now) had not considered how the threshold is initially set, or under what conditions it can be changed.
The simplest is not to allow any interval objects computed at one threshold to be input to operations at a different threshold. One can't tag an individual interval with a threshold value (no room in a "compressed" object for this). One might have a way to "kill" all existing compressed objects at run time when the threshold changes. Or statically stop it ever being possible. Or you could think of other solutions no doubt.
I suggest a "statically stop it" solution by saying that at Level 2 there be a separate compressed type for each threshold value. At language level, different classes or whatever. Then, for an xx1 of compressed type T1, computed at threshold t1, to be input to an operation at threshold t2, it must be explicitly converted to the new type T2.
I see this conversion as hardly ever being a useful thing to do, so there is no need to make it *convenient*. So I would say it should only be possible by converting the T1 compressed interval back to a normal interval and then to a T2 compressed interval.
John