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

[Zoltan Somogyi]

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. In many cases, e.g. for mode errors, finding the correct erroneous
region would be quite difficult.

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

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. Or are you proposing a new predicate that, when given a file name
and a pair of line_columns, returns the region between them? That could
be useful for printing a goal, but not for placing it into context.

Zoltan.