[m-rev.] Handle polymorphic inequality goals

[Fergus Henderson]

On 24-Oct-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> 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.

I'm afraid I still don't see how that would be as efficient
as builtin_int_lt.  Could you please spell it out for me?

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

It's not just the backwards compatibility issue.  There's also the issue
of `integer' and `rational' being less usable after this change.

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

That makes sense; I don't think this change would be an improvement
unless also accompanied by that change, plus a change to implement
user-defined comparison for integer and rational.  (Even then,
I'm still not sure...)

There's also an issue with float: should `<' for floats be IEEE comparison?
Currently it is, and IEEE compatibility is a strong argument for it
remaining that way.  Should "compare" for floats be IEEE comparison?
Probably not, since IEEE comparison does not satisfy compare(=, X, X)
for all X.  That suggests that `<' for floats should not be the same
as compare(<, ...).

If the goal is just to provide nicer syntax for `compare',
perhaps it would be better to provide Prolog-like "@<", "@>", etc.
operators, rather than conflating "<" with "@<"?

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

Because fixed limits are evil, and floating point is the work of the devil ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------