[mercury-users] Collections of closures [polymorphic insts]

[Ralph Becket]

> From: David Overton [mailto:dmo at hydra.cs.mu.oz.au]
> Sent: 11 January 2000 00:57
> 
> One way around this would be to restrict the use of polymorphic insts
> to require that, if a variable of the polymorphic inst is to be
> copied, it must be ground.
> 
> To borrow some syntax from type classes, you could have a
> declaration like:
> 
> :- mode nth(in(list_skel(I)), in) = out(I) is det <= ground(I).
> 
> Which will only accept ground lists as input and return ground
> objects.  There is also a problem with uniqueness analysis.  The
> simple solution to this would be to define that `<= 
> ground(I)' means that
> `I' is shared (i.e. not unique).

That seems fine to me - I'm quite skeptical about the whole
partially instantiated structure thing anyway.  Perhaps a
better place to put the constraint would be on the mode
definition, at least in this case:

:- mode in(I) :: I -> I <= ground(I).
:- mode ui(I) :: I -> I <= unique(I).

and so forth.

> > One possibility is that you end up with an alias of that variable,
> 
> The `<= ground(I)' declaration I've just proposed removes the need to
> record aliasing in the mode declaration.  Alias analysis is an area of
> research I'm currently working on, which would allow more general use
> of polymorphic insts that might be partially instantiated.

How much effort would be required to extend the system as discussed
above without including aliasing?  It would be a significant improvement,
IMHO.  I understand that the compiler has to grok aliasing to handle
nested unique objects, but is that special case easier to handle than
general aliasing?  If so, could that be milestone no. 2?

> > but I've half convinced myself that you should really get a new free
> > variable instead.
> 
> How would you do this and still keep the language declarative?

Yes, I realised the new-free-var idea was broken just after I'd posted it.

Ralph
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------