[m-rev.] For review: solver-types

Zoltan Somogyi zs at cs.mu.OZ.AU
Thu Jul 22 19:15:18 AEST 2004


On 16-Jul-2004, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> --- hlds_data.m	14 Jun 2004 04:16:06 -0000	1.87
> +++ hlds_data.m	14 Jul 2004 06:20:48 -0000
> @@ -129,7 +129,7 @@
>  	% An `hlds_type_body' holds the body of a type definition:
>  	% du = discriminated union, uu = undiscriminated union,
>  	% eqv_type = equivalence type (a type defined to be equivalent
> -	% to some other type)
> +	% to some other type), and solver_type.
>  
>  :- type hlds_type_body
>  	--->	du_type(
> @@ -142,24 +142,26 @@
>  					% is this type an enumeration?
>  			du_type_is_enum		:: bool,
>  
> -					% user-defined equality and
> -					% comparison preds
> -			du_type_usereq		:: maybe(unify_compare),
> +					% Optional user-defined equality and
> +					% comparison preds, but no
> +					% solver_type_details.
> +			du_type_special_type_details :: special_type_details,
>  
>  					% is there a `:- pragma reserve_tag'
>  					% pragma for this type?
>  			du_type_reserved_tag	:: bool,
>  
> -					% should the `any' inst be considered
> -					% `bound' for this type?
> -			du_type_is_solver_type	:: is_solver_type,
> -
>  					% are there `:- pragma foreign' type
>  					% declarations for this type?
>  			du_type_is_foreign_type	:: maybe(foreign_type_body)
>  		)
>  	;	eqv_type(type)
> -	;	foreign_type(foreign_type_body, is_solver_type)
> +			% Optional user-defined equality and comparison preds,
> +			% but no solver_type_details.
> +	;	foreign_type(foreign_type_body)
> +			% Optional user-defined equality and comparison preds,
> +			% and must have solver_type_details.
> +	;	solver_type(special_type_details)
>  	;	abstract_type(is_solver_type).

It looks to me as though this design is insufficiently factored out.
I don't see why you don't have the solver information restricted to the
solver_type alternative, instead of requiring a runtime check on every access.
Now that there is a separate solver_type alternative, the solver info part
of the special_type_details should always be "no" for du_type and foreign_type,
no?

Bunding the solver info with unify and compare info is OK for the parse tree,
but not for the HLDS.

I should have other comments tomorrow; don't commit before you get them.

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



More information about the reviews mailing list