[m-rev.] Handle polymorphic inequality goals

[Ralph Becket]

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

	X =< Y

==> (via alternate simplification)

	not (R = (>), compare(R, X, Y))

==> (via inlining and (in, in, in) is semidet mode specific clause for
compare/3)

	not (	R = (>),
		(	R = (<), builtin_int_lt(X, Y)
		;	R = (=), X = Y
		;	R = (>), builtin_int_lt(Y, X)
		)
	)

==> (via inst propagation)

	not ( R = (>), builtin_int_lt(Y, X) )

==> (via unused variable elimination)

	not builtin_int_lt(Y, X)

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

True.  But "natural" comparisons become simpler and I'd wager they are
vastly more common.

> > 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(<, ...).

The argument works equally well the other way round.

My take on it is this: for most programmers and most programs, exact
IEEE semantics are not relevant.  Hardly anybody knows what they are.
The concerned programmer will not balk at writing X `'float__ieee_<'` Y
where this is an issue.  For the most part, however, I just want to
write X < Y without worrying about strange boundary conditions.  I can't
remember the last time I wrote a program where this would be an issue
(or, at least if it were to be an issue I would have taken much greater
care over the floating point aspects of the program.)

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

Ugh!

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

Yeah, but good performance is nice from time to time :)

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