[m-dev.] for review: program_representation.m

Mark Anthony BROWN dougl at cs.mu.OZ.AU
Fri Sep 1 18:39:34 AEDT 2000


Zoltan Somogyi writes:
> 
> For review by Mark.
> 
> browser/program_representation.m:
> 	New file to hold the definition of the representation of procedure
> 	bodies to be used by the declarative debugger. This is committed now
> 	so that Mark can write code to use this data structure while I write
> 	code to generate it.
> 
> browser/mdb.m:
> 	Mention the new module.
> 
> Zoltan.
> 
> cvs diff: Diffing .
> Index: mdb.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/browser/mdb.m,v

...

> Index: program_representation.m
> ===================================================================
> RCS file: program_representation.m
> diff -N program_representation.m
> --- /dev/null	Wed Jul 26 16:10:00 2000
> +++ program_representation.m	Wed Aug 30 16:46:55 2000

...

These look like earlier versions that were not meant to be part of the
diff, so I've ignored them.

> Index: mdb.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/browser/mdb.m,v
> retrieving revision 1.1
> diff -u -b -r1.1 mdb.m
> --- mdb.m	2000/02/04 03:45:29	1.1
> +++ mdb.m	2000/09/01 01:40:21
> @@ -16,6 +16,7 @@
>  :- include_module interactive_query.
>  :- include_module debugger_interface, collect_lib.
>  :- include_module declarative_debugger, declarative_execution.
> +:- include_module program_representation.
>  
>  :- implementation.
>  
> Index: program_representation.m
> ===================================================================
> RCS file: program_representation.m
> diff -N program_representation.m
> --- /dev/null	Wed Jul 26 16:10:00 2000
> +++ program_representation.m	Fri Sep  1 12:44:23 2000
> @@ -0,0 +1,117 @@
> +%-----------------------------------------------------------------------------%
> +% Copyright (C) 2000 The University of Melbourne.
> +% This file may only be copied under the terms of the GNU Library General
> +% Public License - see the file COPYING.LIB in the Mercury distribution.
> +%-----------------------------------------------------------------------------%
> +%
> +% File: program_representation.m
> +% Authors: zs, dougl
> +%
> +% This module defines the representation of procedure bodies used by
> +% the declarative debugger.
> +%
> +% One of the things we want the declarative debugger to be able to do
> +% is to let the user specify which part of which output argument of an
> +% incorrect answer is actually wrong,

I'm a little bit picky about the meaning of the word 'wrong' here.  Atoms
can be wrong (i.e. not true in the intended interpretation), but I'm not
sure that it makes sense for subterms to be wrong.  I'd prefer it if you
changed this to something like:

	... let the user specify which part of an incorrect or
	inadmissible atom is suspicious ...

This reflects the fact that we will be using this information for heuristic
purposes to direct the search for bugs, but not to determine whether or
not a node is a bug.

> and then find out where that particular
> +% subterm came from, i.e. where it was bound. Doing this requires knowing
> +% what the bodies of that procedure and its descendants are.
> +%
> +% If the Mercury compiler is invoked with options requesting declarative
> +% debugging, it will include in each procedure layout a pointer to a simplified
> +% representation of the goal that is the body of the corresponding procedure.
> +% We use a simplified representation partly because we want to insulate the
> +% code of the declarative debugger from irrelevant changes in HLDS types,
> +% and partly because we want to minimize the space taken in up in executables
> +% by these representations.
> +%
> +% The current representation is intended to contain all the information
> +% we are pretty sure can be usefully exploited by the declarative debugger.
> +
> +:- module mdb__program_representation.
> +
> +:- interface.
> +
> +:- import_module list.
> +
> +	% A representation of the goal we execute.  These need to be
> +	% generated statically and stored inside the executable.
> +	%
> +	% Each element of this structure will correspond one-to-one
> +	% to the original stage 90 HLDS, with the exception of conj
> +	% goal_reps, which are stored in reversed order.
> +
> +:- type goal_rep
> +	--->	conj(
> +			list(goal_rep)		% The conjuncts in reverse
> +						% order.
> +		)
> +	;	disj(
> +			list(goal_rep)		% The disjuncts in the original
> +						% order.
> +		)
> +	;	switch(
> +			list(goal_rep)		% The switch arms in the
> +						% original order.
> +		)
> +	;	ite(
> +			goal_rep,		% Condition.
> +			goal_rep,		% Then branch.
> +			goal_rep		% Else branch.
> +		)
> +	;	negation(
> +			goal_rep		% The negated goal.
> +		)
> +	;	atomic_goal(
> +			detism_rep,
> +			string,			% Filename of context.
> +			int,			% Line number of context.

Why not use a term__context?

> +			list(var_rep),		% The sorted list of the
> +						% variables

That comment is incomplete.

> +			atomic_goal_rep
> +		).
> +
> +:- type atomic_goal_rep
> +	--->	unify_construct(
> +			var_rep,
> +			list(var_rep)
> +		)
> +	;	unify_deconstruct(
> +			var_rep,
> +			list(var_rep)
> +		)
> +	;	unify_assign(
> +			var_rep,
> +			var_rep
> +		)
> +	;	unify_simple_test(
> +			var_rep,
> +			var_rep
> +		)
> +	;	pragma_c_code(
> +			list(var_rep)
> +		)
> +	;	higher_order_call(
> +			var_rep,
> +			list(var_rep)
> +		)
> +	;	method_call(
> +			var_rep,
> +			int,
> +			list(var_rep)
> +		)
> +	;	plain_call(
> +			string,
> +			list(var_rep)
> +		).
> +
> +:- type var_rep	==	int.
> +
> +:- type detism_rep	
> +	--->	det
> +	;	semidet
> +	;	nondet
> +	;	multidet
> +	;	cc_nondet
> +	;	cc_multidet
> +	;	erroneous
> +	;	failure.

The rest of the diff looks fine.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list