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

[Fergus Henderson]

On 09-Mar-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Peter Schachte wrote:
> > Often (usually?) when dealing with source code, what you really want
> > to represent is a *region* of the file.  For error reporting, this
> > would allow you to highlight or underline exactly the part of the code
> > that is in error.  For debugging, it would let you highlight all and
> > only the current goal, even if it spans multiple lines or shares a
> > line with other goals.
> 
> That may be. However, our current error reporting model is not based on
> highlighting the region in error, and we do not collect information on
> regions.

That's true, but in the long run I think it would be a good idea
to move towards the model the Peter Schachte is advocating,
so long as it doesn't have a huge impact on overall compilation time
or memory usage (obviously it will have _some_ impact).

> In many cases, e.g. for mode errors, finding the correct erroneous
> region would be quite difficult.

Why do you say that?

Certainly there are some cases with mode errors in conjunctions where it
is difficult for the compiler to pick which subgoal is really at fault. 
But it has a reasonable heuristic that works most of the time.
And so long as we keep the appropriate information around in the
goal_info, finding the correct erroneous region given the subgoal
should be trivial.

In fact, if we had a really nifty environment, the system could
highlight the goal that the compiler's heuristic said is probably
wrong in one colour, and it could also highlight all the other goals
which might be wrong in another colour.  That could actually be very
useful.

> As a user of the debugger, I would say that highlighting an entire goal
> is very little more useful, and probably more distracting, than just being
> pointed to the start of the goal.

I think that for novice users it could be very helpful to highlight
whole goals.  The distraction effect would wear off very quickly, I suspect.
(I used to use Turbo Pascal and Turbo C, whose debuggers would
highlight the whole line.  You might argue that would be distracting
too, but I found it quite useful and I don't ever recall finding it
distracting.)

> 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.

I presume you mean "a single subgoal in the HLDS", since the HLDS has
subgoals rather than regions.
When can a single subgoal in the HLDS correspond to multiple
regions in the source?

> Peter Schachte wrote:
> > Therefore, I suggest adding a `file_region' type to this module (or
> > maybe you can suggest a better name than this), and operations to
> > convert a file_region to a pair(line_column) based on the database.
> > Given this, I believe term__contexts should hold file_regions, rather
> > than single offsets.
> 
> I don't really see a need for this. A file_region is nothing more than
> a pair of line_columns, and surely the callers of this module can handle that
> themselves.

In this particular case it would be more efficient for the pair
of line_columns to be unfolded into the term__contexts, rather than the
term_contexts containing a pointer to a pair.
So I vote with Zoltan on this one ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.