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

[Ralph Becket]

Zoltan Somogyi, Monday, 16 August 2004:
> 
> If a type is a solver type, then hlds_type_body should be bound to
> solver_type, not du_type or foreign_type. Because of this, the du_type
> and foreign_type function symbols should have no descendant fields of
> type solver_type_details. If they do, as in your design (since
> special_type_details includes a field of type
> maybe(solver_type_details)), then code processing du_types and
> foreign_types must choose between two bad choices: either it has lots
> of error checking code that wouldn't be needed with a better data
> structure design, or it ignores data values that violate the data
> structure's invariants.

I agree.  Including the solver_type_details in the special_type_details
is a hangover from the earlier designs where any type might be a solver
type.  I'll strip that stuff out and revert to unify_compares and just
keep solver_type_details in the solver_type data constructor.  Diff
coming up...

Ta,
-- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------