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

[Simon Taylor]

On 09-Aug-2002, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> > Index: analysis/analysis.file.m
> > ===================================================================
> > +% The format of an analysis file is:
> > +%
> > +% version_number.
> > +% analysis_name(func_id, call_pattern, answer_pattern).
> > +%-----------------------------------------------------------------------------%
> 
> 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").
 
> - 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.

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

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