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

[Peter Schachte]

On Tue, Mar 09, 1999 at 11:46:00AM +1100, Zoltan Somogyi 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.

True, but the current error reporting mechanism is just based on line
numbers.  The idea behind this module is to extend this model; I'm
suggesting extending it a little farther.

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.

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

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.

> 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'd like it.  Matter of taste, I suppose.

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

> 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

More like a pair of offsets.  But there are other possible
implementations (eg, packing an offset plus a length into one int).
At any rate, IMHO it's a sensible enough concept to warrant its own
type.  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.

> Or are you proposing a new predicate that, when given a file name
> and a pair of line_columns, returns the region between them?

No, I'm proposing a predicate that takes two offsets and yields a
file_region, and another that takes a file_region and yields two
line_columns.  And, if needed, a predicate that takes a list of
file_regions and returns the convex hull as another file_region.

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

-- 
Peter Schachte                     Hofstadter's Law: It always takes longer
mailto:schachte at cs.mu.OZ.AU        than you expect, even when you take
http://www.cs.mu.oz.au/~schachte/  Hofstadter's Law into account. 
PGP: finger schachte at 128.250.37.3