[m-rev.] Handle polymorphic inequality goals

[Ralph Becket]

Fergus Henderson, Thursday, 24 October 2002:
> 
> Hmm.  Is the compiler really still capable of generating efficient code
> for `X < 42'?
> 
> It would need to do a quite complicated set of transformations:
> 
> 	X =< Y
> 
> ==> (via your change to simplification)
> 
>  	some [R] (compare(R, X, Y), R \= (>))
> 
> ==> (via specialization)
> 
>  	some [R] (
> 		builtin_compare_int(R, X, Y),
> 		R \= (>))
> 	)
> 
> ==> (via inlining)
> 
>  	some [R] (
> 		( X < Y ->
> 			R = (<)
> 		; X = Y ->
> 			R = (=)
> 		;
> 			R = (>)
> 		),
> 		\+ (R = (>))
> 	)
> 
> ==> (how???)
> 
> 	\+ builtin_int_gt(X, Y)

We could add

	:- mode compare(in, in, in) is semidet.

(and maybe some mode specific implementation detail), change the
transformation to

	X  < Y	--->	compare((<), X, Y)
	X =< Y	--->	not compare((>), X, Y)
	etc.

and Bob's your uncle.

> Also, isn't there a problem with int:(X < Y) calling builtin__compare
> calling private_builtin__builtin_compare_int calling int:(X < Y)??

Yes, you're right.  The proper definition of
builtin_compare_int/3 would be

builtin_compare_int(R, X, Y) :-
	( X `private_builtin_int_lt` Y -> R = (<)
	; X = Y                        -> R = (=)
	;                                 R = (>)
	).

The first condition should not be just X < Y as it currently stands.

Thanks for spotting that one.

> > library/integer.m:
> > library/rational.m:
> > 	Fully qualified calls to the integer and rational inequalities.
> 
> Isn't this change going to break any user code which uses `<' or similar
> on `integer' and `rational' types?

They knew the risks :)

Seriously, I don't think we're going to upset enough people to not want
to make the change.

Simon posted a patch to allow user-defined comparison a while back.  I
think we should reconsider not making that change.

> If so, then it sounds to me like the cure may be worse than the disease.

I disagree.  I don't believe we'd upset enough users.  If we added
Simon's change then we wouldn't upset anyone.

> > Index: library/integer.m
> > ===================================================================
> > RCS file: /home/mercury1/repository/mercury/library/integer.m,v
> > retrieving revision 1.9
> > diff -u -r1.9 integer.m
> > --- library/integer.m	29 Aug 2002 10:09:07 -0000	1.9
> > +++ library/integer.m	3 Oct 2002 08:58:20 -0000
> > @@ -1054,7 +1054,9 @@
> >   
> >  %:- func integer__int(integer) = int.
> >  integer__int(Integer) = Int :-
> > -    ( Integer >= integer(int__min_int), Integer =< integer(int__max_int) ->
> > +    (   integer:'>='(Integer, integer(int__min_int)),
> > +        integer:'=<'(Integer, integer(int__max_int))
> > +    ->
> 
> ":" should not be used for module qualification.
> Use "__" instead, and preferably infix rather than prefix,
>  e.g.  "Integer `'integer__>='` integer(int__min_int)".

Righto.

> This syntax is horrible.  It makes the `integer' and `rational' types
> very painful to use.  I'd rather we make changes which make it easier
> to use `integer' and `rational' and harder to use `int' and `float'
> than vice versa.

Why?

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