Re: Rewrite of PROPOSAL 001213.1 re default location [resend #8]

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

Michael Eager writes:
>There seems to be a significant drift in this discussion.
>
>The topic is a proposed default location attribute.  This discussion 
>seems to be about debugging optimized code.  I think that discussion 
>which wanders far afield from the subject is not very productive.

The proposal was offered as what I have found to be a simple but often
effective optimization for a commonly occurring pattern of use for location
lists; at the time it never occurred to me that we would discover such
divergence of opinion over what the standard means by "When [address ranges
overlap], they describe a situation in which an object exists in more than
one place."

Since the validity of the optimization depends in part on what overlapping
address ranges really mean, it is natural that we should "drift" into
discussion of those underlying issues.

But perhaps we have gone too far afield. I did try at the end of my previous
mail to refocus the discussion on resolution of the ambiguity we discovered
(the three suggested alternatives).

I do think the discussion has been very productive in the sense that it
has exposed a rather significant ambiguity and divergence in our understanding
of the standard. Resolving that problem now counts far higher in my personal
list of priorities than the original proposal.

>Your proposal about default location attribute does not seem to address
>this.  Indeed, it seems to contradict your current argument in that it 
>describes a default location and alternate locations for a single object.  

The proposal does not address this choice because it assumed what I thought
was the obvious and appropriate interpretation. (Obviously, we now see it
isn't so obvious.)

I don't understand the suggestion of a contradiction. 001213.1 says, if you
see a particular pattern of location list entry use then here is a
tranformation using another attribute that can be used to express the same
information more compactly. How is that a contradiction?

>It appears to me that your "multiple distinct values model" can be 
>represented within the current standard.

What "current standard" is that? The one whose overlapping location list
entry interpretation we are debating about?

But quite seriously, do please elaborate. I can see how the "multiple
distinct values" model can be used to represent any location list that
the "single location, last to match" model can represent, but I don't
see how the converse statement can possibly be true. Moreover, I don't
see that there is any similar inclusion relationship between any of the
other pairs of models (in either direction). If there are such
relationships if help to know because they can provide a basis for
preferring one model over another as being the more general, more flexible.

At this point I am quite willing to withdraw 001213.1. It has served
a purpose, although not the one originally intended. The optimization
proposed is small potatoes in the grand scheme of things and I see little
benefit to continued discussion of that proposal as such.

But the ambiguity uncovered as part of the discussion remains. I do hope
we can resolve it one way or another and not just let it drop along with
the original proposal.

Perhaps it would be useful to conduct a "straw vote" by email? Each person
can simply indicate which of the three candidate interpretations they
currently favor. (See the last part of my earlier email of today, 17 January,
on this same topic for the apparent list of alternatives.) If that vote
indicates a consensus for one intrepretation in particular, then I think
we can easily work out some supporting textual changes to support it and
be finished with this subject rather quickly.

How say ye?