[m-rev.] for discussion: subtypes documentation

[Mark Brown]

On 25-Nov-2002, David Overton <dmo at cs.mu.OZ.AU> wrote:
> On Sun, Nov 24, 2002 at 10:36:55PM +1100, Mark Brown wrote:
> > 	- I've expounded on subtypes a little bit more in the modes
> > 	  section, describing subtype information as being attached
> > 	  to the and-nodes of a type tree.  That was the simplest way I
> > 	  could find of describing the semantics of subtypes.
> 
> I've used a different approach to describing this sort of stuff in my
> thesis.  I define a couple of partial order relations on insts and use
> them to describe most of the other relationships and operations on
> insts.  You may get some ideas there.  For example, it would allow you
> to describe the propagation of base insts into modes as simply taking
> the least upper bound.
> 
> You can see the latest draft by checking it out of the cvs repository at
> `~dmo/repository/thesis'.  See chapters 3 and 4 in particular.

Ok, that approach works for me.

>
> > +The values described by a subtype are meant (for first order types)
> > +to be a subset of those described by the supertype.
> 
> Do the values have to be a _strict_ subset?

No.

> If not, then it might be
> better to use '=<' rather than '<'.  This would also make it more
> consistent with the syntax used for constrained polymorphic modes.

Actually, as discussed in another post the partial order I gave is
different to the order used by inst constraints, so that is a reason
to avoid '=<'.  If we do end up using the same order, however, then
using '=<' is definitely a good idea.

> 
> Also, I'm a bit concerned about the word "meant".  Is this enforced by
> the compiler?

Yes.

> > +
> > + at item
> > +If it is a pred or func type, the base inst is just the subtype itself.
> > +This is not a valid Mercury inst, so attempting to use it directly
> > +will result in an error.
> > +However, if a base inst like this is propagated into another inst,
> > +as described below, then a valid inst may result
> > +and using this resulting inst would therefore not be a problem.
> 
> This sounds rather complicated.  Couldn't you just map to a base inst of
> ground unless an inst qualifier is given?  I think that would work the
> same when you do the propagation (provided you add a row to your
> propagation table, as I've done below).

Ok, that is better.

Cheers,
Mark.

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