[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