[m-dev.] for review: new module for handling file offsets

[Zoltan Somogyi]

Peter Schachte wrote:
> The trouble with a single offset is that it just points to a single
> character in a file, implicitly saying "what you're interested in is
> somewhere after this."  With a region, you're explicitly specifying
> your precision.

Yes, I know that. My point is that we can't easily *use* the extra
precision, at least not with any proposal I have seen so far (although
I'd be glad to be proven wrong). You can only meaningfully highlight
a region in the source if you display some source. We don't display
source, and the kind of IDE you are asking for is out of our reach
for the moment.

Peter Schachte wrote:
> Just because you *can* be precise doesn't mean you have to.  You could
> just point to the first goal that shows the mode problem.  If you can
> point to a specific argument, great.  If you can't even pinpoint a
> goal, just point to a whole conjunction, or even a whole clause.

Basically, for mode problems you want to say "here are a bunch of conjuncts,
taken from all over a conjunction, from which I can't schedule any conjunct
first". That is not a single region, but several, at least in general.

Peter Schachte wrote:
>> Yes, in some cases (e.g. a call at the start
>> of a conjunction), this indication can be ambiguous. However, representing
>> a goal by a region does not completely eliminate the ambiguity, since due to
>> mode reordering, a single region in the HLDS can correspond to multiple
>> regions in the source.
> 
> Sure, that can happen, but you can always take the convex hull in such
> cases.  It's probably better than pointing somewhere in the middle of
> the source.

I disagree. For diagnosing a mode problem, you definitely want to present
the smallest set of unschedulable goals. Anything else is significantly
suboptimal; I don't care how pretty the colours are.

Peter Schachte wrote:
> > I don't really see a need for this. A file_region is nothing more than
> > a pair of line_columns
> 
> More like a pair of offsets.  But there are other possible
> implementations (eg, packing an offset plus a length into one int).

All those are of course equivalent, in the sense of being interconvertible.

> At any rate, IMHO it's a sensible enough concept to warrant its own
> type.

Yes, provided you can *use* that type. I am saying that at the moment,
we can't.

Peter Schachte wrote:
> Particularly if you accept my argument that a range is a better
> entity for indicating a place in source code than a single character
> position.

and:
> But mainly I'm proposing that a term__context hold file_region rather
> than an offset.

That would be a nice goal to shoot for eventually. But right now,
that would require lots of changes throughout the compiler, since
at the moment we just copy term contexts, and we would need to change
that so that in every such place we did something else appropriate.
Unless one can show how we can use regions to improve the output we
give to users, *and their proposal is implemented*, the work required
by those modifications is not justified.

Zoltan.