[m-dev.] subtypes discussion

[Fergus Henderson]

On 03-Jan-2003, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> On 30-Dec-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> > Given this, I'm happy to agree to position (1).
> 
> Here's an outline of the planned implementation.

Did we resolve what happens if subtypes are used in the RHS of type
definitions?  If so, what was the conclusion?

> 1) Parsing is straightforward. A 'subtype' operator will be added
> (precedence 1199) to the operator table, and an extra arm added to the item
> type to contain info about subtype declarations.  During parsing we will do
> basic checks, such as checking that type variables appear in the head when
> required.
> 
> 2) We calculate the base type for each subtype by expanding out the
> definitions in a way simlar to expanding equivalence types.  While doing
> this we check for circularities in the subtype declarations (that is,
> places where attempts to calculate the base type would loop) and report
> them as errors.
> 
> 3) At the same time as calculating the base type, we calculate the base
> inst.  We check that the declared subtype represents a subset of the
> supertype using inst_matches_initial, and report an error if it doesn't.
> 
> 4) Propagation of a base inst into another inst will be done in a way
> similar to abstractly_unify_inst and inst_merge.  This means we will add
> a new inst_name, propagate_inst/2, which has the two insts in question
> as arguments, and add a new field to the inst table to store the results.
> The algorithm for propagation is almost identical to that for abstract
> unification; the only significant difference is in how higher order terms
> are handled.

That all sounds fine.

> Aside from feedback on the above, I need advice about where the
> transformation should be done.  That is, at what point in compilation should
> the types in pred/func declarations be replaced by their respective base
> types, and the insts be replaced by those that result from propagating the
> base inst?

The types should be replaced at some point before type-checking.
Not sure exactly when.

The insts should probably be replaced at about the same time that we call
propagate_types_into_modes (or is it propagate_type_list_into_mode_list?);
that is, after type checking, but before mode analysis.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------