Re: tetrits motion: I claim "valid" is not a decoration field
Nate, P1788
On 24 Apr 2010, at 20:11, Nate Hayes wrote:
> I did frame a discussion of this motion as it applies to the "domain"
> attribute in my post yesterday. It is still relevant.
>
> I fear such an analysis demonstrates the proposed propagation mechanism
> would be a setback for P1788; it deviates too far from the semantics we
> agreed on in Motion 8. For example, Motion 8 specifically identifies the
> purpose of decorations is to help disambiguate between
> X \union {empty} = X and X \union NaI = NaI,
> where "NaI" is really some bare decoration. But the definitions being
> proposed in the current motion implicitly "undo" this disambiguation,
> leaving us, to some extent, back where we originally started about a year
> ago.
Thank you pointing this out. I have been (over-?) loudly advocating that
(1) the interval part of a result should depend only on
the interval part of the inputs, not of the decoration.
While failing to remind myself (and everyone) that
(2) "valid" is a special case.
(a) It's a Boolean property: "possiblyValid" isn't used, or in the tetrit scheme xx can't be partly valid and partly not.
(b) If xx is invalid it has become a "black hole". It is simply impossible to attribute any features to it, except the fact of being invalid.
Well not quite. There has to be a "convert to bare interval" function, and I think we agreed when applied to invalid xx it returns Empty.
So here's a case where the result of an operation is determined *entirely* by the decoration part of the (invalid) input -- the reverse of (1).
Nate: you invented this scheme (see above) because
(3) "valid" gives a *more efficient* way to implement NaI,
right? But it seems to me the correct conceptual way to view "valid" is that
(4) "valid" is not a field in the decoration,
but a value of the interval-part.
*Conceptually*, mind you. As *implemented* it is indeed a field in the decoration, to achieve (3).
If we adopt (4), this in effect revives NaI as (a possible value of) a Level 2 datum -- in an efficient form at Level 3. It relieves us from needing to reconcile the behaviour of "valid" with that of other decoration properties.
Actually, the effect is that NaI then exists for decorated intervals, but not for bare ones. That seems very sensible.
> I believe a priority mapping, as outlined in my position paper, is required
> to overcome this difficulty and integrate the very nice idea of tetrits into
> a reliable exception handling mechanism consistent with Motion 8 semantics.
> Although I have made a position paper available, there has not been any
> discussion about it in the short time before the current motion.
>
> I'm a little skeptical that we really need to partition decorations into
> "most recent operation" vs. "history,"
I also, but I need to study the discussion more deeply.
Regards
John