[m-rev.] for review: make pred names for lambdas unique

[Zoltan Somogyi]

On 24-May-2005, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> So I propose that I reverse the part of Zoltan's diff that introduced 
> the user friendly predicate names.  Are there any objections to doing 
> this?

Yes; I object.

> >>I'm not sure if I've done this change correctly.  There seem to be 
> >>two places
> >>where the predicate name of a lambda expression is computed.  Once 
> >>when it gets
> >>added to the hlds (in lambda.m) and then again when the C code is 
> >>generated
> >>(in layout_out.m).  I have no idea why this is done twice.

It is not a good idea to change what you haven't understood.

> >I'm not sure I can answer that question, but this change will
> >(presumably) affect the profilers as well, so will also
> >need to look at:
> >
> >	deep_profiler/read_profile.m
> >	profiler/demangle.m
> >	util/mdemangle.c
> >
> 
> None of these seem to comform to the new user friendly pred names 
> anyway.

There are two names involved, because there are two purposes.
The names given to predicates in the HLDS, including the ones created
by lambda.m, are designed to be unique, because the names of the C labels
and functions implementing them are derived from those names. However,
the naming schemes we use to ensure uniqueness also ensure that the
names are in many cases quite ugly and hard for users of the debugger
to deal with.

The names generated by layout.m from the pred_origin fields of
pred_infos are designed to solve this problem. These names were not
designed to be unique in absolutely all circumstances (although they were
not designed to be wantonly nonunique either), since their only intended
use was for display to users, and readability was a higher priority.
These names are never used to generate symbols in object files,
which is why you didn't need to change any of the mangling code.

> >>Does the predicate name generated in lambda.m need to be 
> >>the same as the one generated in layout_out.m?

No; they have different purposes, as explained above.

The problem you ran into is that the code for generating slices
wants to use the not-guaranteed-to-be-unique pretty predicate name
in proc layout structures as if it were a unique indentifier of
predicates, and it isn't.

There are two possible classes of solutions.

First, you can expand the proc layout structure to include not just
the pretty name, but also the ugly but guaranteed to be unique name.
The debugger would use the former, the slicer would use the latter.
Most predicates are user-defined, not compiler-generated,
and for these the two names coincide, so the cost would be an extra
word per predicate in the executable; say 80 kilobytes for the compiler.
However, you'd also have the problem that the predicate names presented
by the slicer are still ugly for compiler-generated predicates,
unless the slicer also records the user-friendly names, for use when unique.
This would probably increase the size of slice files by a significant
percentage.

Second, you can change the naming scheme for the pretty names generated
by layout_out.m to actually be unique. This is what your diff does, but
it does not keep the names pretty or predictable. Using the name
lambda_4_higher_order_21 to refer to the lambda expression on line 21
of higher_order.m is bad because the user can't put a breakpoint on
that lambda expression without counting the number of lambda expressions
before that point in the code (since the 4 is a sequence number, incremented
for each lambda expression encountered by the compiler).

The best solution would approach 2, but keeping the names of lambda expression
predicates as they are now, except when there is more than one lambda
expression on a line. The way to achieve this would be to replace the
lambda_number_counter field of the module_info with a map from contexts
(filename/linenumber pairs) to the number of lambda expressions found
so far at that context. In the vast majority of cases, there won't be any,
and we can record the pred_origin (on line 576 in lambda.m) as
lambda(OrigFile, OrigLine, 1). If the map says there were already two other
lambda expressions on that line, we can record it as lambda(OrigFile,
OrigLine, 3). When layout_out.m converts these into user-friendly names,
it can generate names like this:

lambda_higher_order_21
lambda_higher_order_21_2
lambda_higher_order_21_3

You'd have to do something more about uniqueness (does lambda_higher_order_21_3
represent the third lambda on line 21 in higher_order.m, or the first lambda
on line 3 in higher_order_21.m?), but that should be doable while keeping
the names readable.

You can of course go with both approaches simultaneously.

Any further discussion on this would best be done in person.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------