[m-rev.] for review: record extras information about user-defined equality/comparison

[Zoltan Somogyi]

On 12-Jun-2004, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> +set_type_defn_user_equality(PPId, Defn0, Defn) :-
> +	(
> +		Status = Defn0 ^ type_defn_import_status,
> +		status_defined_in_this_module(Status, yes)
> +	->
> +		true
> +	;
> +		error(
> +		"set_type_defn_user_equality/3 called with non-local type.")
> +	),

What is the rationale for this check? I can think of circumstances (e.g.
exception analysis) in which this information would also be useful for
types defined in other modules.

> +	UserUC_Preds0 = Defn0 ^ type_user_uc_preds,
> +	(
> +		UserUC_Preds0 = no,
> +		UserUC_Preds  = yes(user_uc_ids(yes(PPId), no))
> +	;
> +		UserUC_Preds0 = yes(user_uc_ids(_, MaybeCmpPPId)),
> +		UserUC_Preds  = yes(user_uc_ids(yes(PPId), MaybeCmpPPId))
> +	),
> +	Defn = Defn0 ^ type_user_uc_preds := UserUC_Preds.


>  	% Stage number assignments:
>  	%
> -	%	 1 to 25	front end pass
> -	%	26 to 50	middle pass
> +	%	 1 to 24	front end pass
> +	%	25 to 50	middle pass
>  	%	51 to 99	back end pass

It looks like it is time to switch to three digit stage numbers,
or to a scheme like

	fNN for the front end
	mNN for the middle passes
	bNN for the back end

What is the reason why this information cannot be gather when the predicates
you are analysing here are first constructed, in unify_proc.m?

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