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

[Peter Schachte]

On Tue, Mar 09, 1999 at 04:47:06PM +1100, Zoltan Somogyi wrote:
> Peter Schachte wrote:
> > 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.

I don't understand why switching from line numbers to file offsets is
so much easier than switching to file regions.  I don't see why the
increased precision of the offset doesn't present most of the same
problems as regions would.  And in any case, I don't see that just
adding column information is a very significant improvement,
particularly if there's a danger it won't be accurate.  The more
precise you are the more you have to worry about accuracy.

Alright, how about this as a compromise position: add an abstract type
called something like file_content_identifier (but preferably shorter)
to signify that it specifies some part of a file.  Use this type
instead of integer offsets in your module.  And then just add the word
``start'' somewhere in the predicates that get the line and column
from an offset so that it's clear that you are getting the line and
column numbers of the start of the specified part of the file.  This
just encapsulates what you're doing better so that later it would be
easier to switch to some fancier way of identifying part of a file.


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