[m-rev.] for review: inter-module analysis framework

[Nancy Mazur]

> > The problem is elsewhere, and I'll try to illustrate it with the
> > following: 
> > 
> > - append. As said earlier, a type-info headvar is added to it... so
> > evaluating proc_info_headvars/2 in the case of append gives me a list
> > of 4 variables. A priori, I don't know which of them are the actual
> > headvars, and which one of them is the artificial added one? Is it the
> > first? The last? I might filter them out by removing the type-info's
> > explicitly, but then what about those exceptional cases where the
> > predicate _is_ explicitly defined with type_info's (like in std_util
> > somewhere), or what if new additional artificial variables are
> > introduced? 
> > - okay, so I don't filter it out, and I have to work with those 4
> > variables. No problem, I dump my CTGC-information by listing those
> > 4 variables first, and then the actual success-pattern... 
> > - note that the interface file of the module in which append is defined
> > declares a predicate with arity 3. 
> > - and now comes the problem-part. When compiling a module, say 
> > "use_append", which imports the module where append is defined, then 
> > the corresponding pred_info's en proc_info's are created for append
> > (with empty body of course), but with only 3 headvars... at this stage
> > the analysis file of append is read, but there my information is in
> > terms of 4 headvars! which ones do I have to match with? because in
> > order to be correct, my CTGC-information needs to be renamed to those 3
> > headvars.. 
> 
> So you can't do anything with the analysis information until
> after polymorphism has been run. Where's the problem?

Haven't thought of that... so you mean: read in all the analysis-info in
the beginning, but don't do anything with it until the analysis-pass
itself which, as a preparation, has to run over all imported predicates
and procedures and process the interface-information that was
read in... But do I have a guarantee that all the imported preds and
procs will be reshaped (as far as their headvars concerns) to the same
shape as when they were actually analysed? Where can I find this
guarantee? 

> > At this moment the type-info's are artificially removed, but I don't
> > like this solution. In an earlier stage I duplicated the field for 
> > the headvars in proc_info "before" additional headvars where being
> > created, but now something else is being done with these headvars (and I
> > suppose the link you've given me here will give me the solution), so 
> > that suddenly didn't work as supposed... 
> 
> This is why trying to treat the "original" variables as a special
> case is a bad idea. The compiler makes no distinction between
> original and introduced variables, so minor changes will break
> any code which attempts to make the distinction.

I must say, I have more faith in outputting information w.r.t. the
original predicate declaration, then w.r.t. a transformed predicate
declaration for which I may not have the guarantee that it will be
transformed in the same way when read in... 
whereas I do have that guarantee for the original predicate declaration,
as that is also the declaration that is put into the .int files. 

But it may be worth trying that line of thought you pointed out... 
(if I can be sure that the same extra artificial vars are added once the
preds are being imported)... 
Nancy

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