[m-rev.] for review: constrained polymorphic insts

[David Overton]

On Thu, Feb 21, 2002 at 06:40:38PM +1100, Fergus Henderson wrote:
> On 21-Feb-2002, David Overton <dmo at cs.mu.OZ.AU> wrote:
> > Index: doc/reference_manual.texi
> ...
> > + at node Constrained polymorphic modes
> > + at section Constrained polymorphic modes
> > +
> > +Mode declarations for predicates and functions may also have inst parameters.
> > +However, such parameters must be constrained to be @emph{compatible} with some
> > +other inst.
> > +The construct @samp{@var{InstParam} =< @var{Inst}},
> > +where @var{InstParam} is a variable and @var{Inst} is an inst,
> > +states that 
> > + at var{InstParam} is constrained to be @emph{compatible} with @var{Inst},
> > +that is,
> > + at var{InstParam} represents some inst that can be used anywhere where
> > + at var{Inst} is required.
> > +If an inst parameter occurs more than once in a declaration, it must have the
> > +same constraint on each occurrence.
> 
> It's not clear from these words what kind of construct InstParam =< Inst is,
> or where in the syntax it is allowed to appear.  From the example below,
> I can guess that this construct is actually an inst, but this should be
> stated explicitly.

Okay, I'll fix that after we decide what syntax we actually want to use.

> 
> > +For example, in the mode declaration
> > + at example
> > +	:- mode append(in(list_skel(I =< ground)), in(list_skel(I =< ground)),
> > +	        out(list_skel(I =< ground))).
> 
> Wouldn't it be more consistent to use a syntax similar to the
> one that we use for type class constraints, e.g.
> 
> 	:- mode append(in(list_skel(I)), in(list_skel(I)),
> 	        out(list_skel(I))) <= I =< ground.
> 
> ?

Yes, I think something like this would be better.  I went for the
easiest option to implement to start with.

> Also, is it permitted to constrain one inst parameter as being
> compatible with another?
> 
> 	:- mode foo(in(I =< ground), in(J =< I)).

Yes, it is permitted.  I'm not sure if it's useful though.
For example, if there was a call

	foo(X, Y)

where X has initial inst bound(c) and Y has initial inst bound(d) then
the inst parameter substitution is {I -> bound(c ; d), J -> bound(d)}.
So the constraint `J =< I' has the effect of ``widening'' I rather than
``narrowing'' J.

-- 
David Overton      Computer Science and Software Engineering
PhD Student        The University of Melbourne   +61 3 8344 9159
Research Fellow    Monash University (Clayton)   +61 3 9905 5779
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------