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

[Nancy Mazur]

Hi Simon, 

I have a small question.. 

> Index: analysis/analysis.file.m
> ===================================================================
> RCS file: analysis/analysis.file.m
> diff -N analysis/analysis.file.m
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ analysis/analysis.file.m	7 Aug 2002 15:31:37 -0000
> @@ -0,0 +1,327 @@
> +%-----------------------------------------------------------------------------%
> +% An analysis file contains analysis results for a single module.
> +:- module analysis__file.
> +
> +:- interface.
> +
> +:- pred read_module_analysis_results(analysis_info::in,
> +	module_id::in, module_analysis_map(analysis_result)::out,
> +	io__state::di, io__state::uo) is det.
> +
> +:- pred write_module_analysis_results(analysis_info::in,
> +	module_id::in, module_analysis_map(analysis_result)::in,
> +	io__state::di, io__state::uo) is det.
> +
> +:- pred read_module_analysis_requests(analysis_info::in,
> +	module_id::in, module_analysis_map(analysis_request)::out,
> +	io__state::di, io__state::uo) is det.
> +
> +:- pred write_module_analysis_requests(analysis_info::in,
> +	module_id::in, module_analysis_map(analysis_request)::in,
> +	io__state::di, io__state::uo) is det.
> +
> +:- pred empty_request_file(analysis_info::in, module_id::in,
> +	io__state::di, io__state::uo) is det.
> +
> +%-----------------------------------------------------------------------------%
> +:- implementation.
> +% 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...

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

where length(headvarlist) = arity of the predicate/function. 

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

Any ideas on this? 

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