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

[Zoltan Somogyi]

> I thought Mercury could do structure unfolding (untupling) now, no?

No, it cannot, not yet. There is noone working on this directly, either.
To do good job, i.e. one that guarantees not only correctness but also that
performance is not reduced, you need a precise cost model.

> If not, that might be a good reason to implement regions as a separate
> datatype:  it'll add another motivation to implement untupling, which
> would be useful in all sorts of contexts.

It is not the motivation that is lacking; it is manpower.

> In any case, it might be worth considering packing a whole region into
> a single int (18 bits for region start and 14 for size would allow for
> 256K byte files and 16K byte regions, which would almost always be
> enough for human-written code; on 64 bit machines there's plenty of
> room).  Of course, if you store the region as two separate ints, then
> you can't do that, so from the standpoint of efficiency, the separate
> type could be better.

It's the "almost" part I am worried about. Yes, I have used such encoding
tricks in the past, but I don't like them in cases where the actual values
used in practice are so close to the limits we must impose.

> It might even be a good idea to make it a type
> class, so it could store multiple disjoint regions, or have a
> secondary region in cases where two things conflict.

I don't see how type classes would help in this case. Contexts are included
in HLDS, so we can't make contexts a type class until existential types
in data structures are implemented; they are not yet.

Zoltan.