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

If you compile in Emacs, it will already move the cursor to the
appropriate line number.  If the compiler provided the right information,
then I think it would not be difficult to get emacs to highlight a region.
I would in fact be surprised if someone hasn't already done this for
some other language.

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

Sure, but you want a different message for each region anyway.
(I can't schedule *this* region because of *this*, and I
can't schedule *that* region because of *that*, and ...)

So I think using regions would help in this case.

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

Using a single region would be suboptimal.  But using a list of
regions is better than using a list of line & column numbers.

> 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 thought you were arguing that this was of general utility?

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