[m-rev.] for review: merge foreign_type pragma on to the main branch

[Fergus Henderson]

On 23-Oct-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 22-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > +++ compiler/unify_proc.m	22 Oct 2001 14:05:45 -0000
> > @@ -756,6 +756,16 @@
> >  		unify_proc__quantify_clauses_body([H1, H2], Goal, Context,
> >  			Clauses)
> >  	;
> > +		{ TypeBody = foreign_type(_, _) },
> > +			% XXX Is this the correct thing to do?
> > +			% I assume at code gen time I could examine the types
> > +			% of the unification and output different code because
> > +			% they are foreign types.
> > +		{ create_atomic_unification(H1, var(H2), Context, explicit, [],
> > +			Goal) },
> > +		unify_proc__quantify_clauses_body([H1, H2], Goal, Context,
> > +			Clauses)
> > +	;
> 
> I'm not sure whether this is the right thing to do right now either. 
> I'm not entirely sure what code that unification is going to eventually
> generate.

This will result in a recursive call to the unification procedure.
So you'll get an infinite loop.

The code that is generated for compare/3 has the same problem.

A better approach would be to throw an exception,
e.g. by calling a procedure defined in library/private_builtin,
similar to builtin_compare_non_canonical_type.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------