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

[Nancy.Mazur at cs.kuleuven.ac.be]

> > I don't understand how this format works. 
> > 
> > - What do you mean by version_number? Could it be possible to give an
> > example of such a file for a particular analysis? for example by
> > giving the analysis-file of your test-case for unused_args_analusis...
> 
> The version number is needed so that when the format of the file
> changes the library can recognise and recreate files created by
> old versions of the library.
> 
> The analysis file for unused_args_analysis2.m in the test case is:
> 	1.
> 	unused_args("predicate `p2/2\'-0", "", "1").

So that version number is just once for the whole file? ic.. 

> > - in CTGC I always struggle with variable namings and renamings.
> > Typically, our answer_pattern will express some relations between the 
> > headvariables of the predicate to which the annotation belongs. This
> > means I need to list these headvariables explicitly, or else I'm not
> > able to properly rename the variables when reading in this
> > analysis-file. Having these variables right is a real pain for the
> > moment: CTGC-analysis is performed at stage 49 so different type-info's
> > are added to the pred-/proc-info's headvars, and it's hard to extract the
> > original head-variables at that stage. I presume that each analysis
> > which needs to report on the headvariables of a predicate has that
> > problem (if the analysis is performed "after" the type-info's & Co. 
> > have been added). So for me it would be of particular interest
> > to have information reported in the form: 
> > 
> > analysis_name(func_id, headvarlist, call_pattern, answer_pattern). 
> 
> These file formats aren't user-visible.

of course.. 

> Anyway, there's no reason why that information can't be included in
> `call_pattern' and `answer_pattern'.
> 
> For the unused arguments example, you would use a type such as:
> 	:- type unused_args_answer
> 		---> unused_args_answer(
> 				all_args :: list(prog_var),
> 				unused_args :: list(prog_var)
> 		).
> 
> In the analysis database, that would look something like:
> 	unused_args("predicate `p2/2\'-0", "", "[A,B],[A]").
> 
> Why would an analysis pass care what the "original" head variables were?

I mean "original" in the sense: no compiler-added variables. So that 
the arity corresponds with the declared arity. If you import a file
with a polymorphic predicate p/2, you need to have the analysis-info
available for this predicate in terms of the two headvars only (or else
the renaming comes into trouble)... 

> > Analyses that do not need this information can leave the list empty, 
> > or simply not use the information, but for analyses that do, this can 
> > be handy, and will possibly factor out some code that would be common
> > anyhow... 
> 
> The aim of this library is to avoid analysis- and compiler-specific
> details, like "head variables", by factoring those details out
> into type-classes.

Okay, so I'll just solve my problem myself ;-) 
But by the way, these head variables are not analysis- nor
compiler-specific in my opinion... 

Ciao ciao, 
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
--------------------------------------------------------------------------