[m-dev.] Replacing lists of items with a more structured representation

[Zoltan Somogyi]

I have been working on replacing the representation of the program
at the parse_tree level from a list of items (which had to be scanned
far too often and whose invariants were never documented) with a more
structured representation, in which a parse tree unit consists of
a list of regions (interface, implementation, and some others imported
from .int* and .*opt files).

When I changed the representation in prog_item.m and recompiled, I got
many thousands of lines of error messages, from lots of files. I have
been slowly working my through them. I finally got the compiler to compile
again, and (after a few bugfixes) it even works on some small, single-module
files. However, there are still more bugs to track down.

While I was converting old code to use the new representation, I found
lots of places where the code was a bit strange for no good reason that
I could see. I marked those places with XXXs or ZZZs. I would like to
ask the help of those who have worked with the item_list representation
to have a look at the current version of the diff (which is far from
final yet), especially the parts marked by XXX or ZZZ, and give me feedback,
since I think this kind of review will be a more effective method of
finding and fixing bugs than using mdb.

One important thing I would like to ask you to watch out for is error
handling. The old code recorded errors in two ways: a list of "messages",
and an indication which could be no errors, some errors or fatal errors.
Fatal errors were things like the inability to open files; syntax errors
were usually handled as "some errors". I replaced this scheme with a list
of error_specs, some of which are from phase_read_files. The old code
threw away error messages in several places, and in some cases treated
"some errors" as worse than "fatal errors". I changed some of these places
(the ones that didn't look right to me), but it seems that some actually had
(undocumented) reasons for being the way they were. If you know about
this, I would especially value your input.

The diff is in ~zs/mer/parse_tree_unit_ws/DIFF.CVU. For several files,
the diff is bigger than the file (the diff is 34248 lines), so the source
files are there in the workspace as well. (A summary of the diff is
in DIFFSIZES.)

Thanks in advance for any assistance. I intend later to track down
any bugs remaining after this exercise.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------