[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] R7RS-large comparators

This page is part of the web mail archives of SRFI 114 from before July 7th, 2015. The new archives for SRFI 114 contain all messages, not just those from before July 7th, 2015.

Andrew Robbins scripsit:

> This is a comment about
> http://trac.sacrideo.us/wg/wiki/ComparatorsCowan
> I noticed some issues and should like to make comments about this possible
> SRFI/module.

Thanks for the feedback.  Note that this is now a draft SRFI, so
I am copying my response (which contains yours in its entirety) to
<srfi-114@xxxxxxxxxxxxxxxxx>.  Please continue the discussion there; you
can sign up at <http://srfi.schemers.org/srfi-list-subscribe.html>.

The most recent editor's draft is always at
<http://ccil.org/~cowan/temp/srfi-114.html>; this is usually, but not
always, the same as <http://srfi.schemers.org/srfi-114/srfi-114.html>.

> General Issues:
> It is my personal opinion that this module should be helpful to anyone
> involved in either total orders or partial orders, such as floating-point
> numbers (which form a total order if you ignore NaNs and -0.0). One way of
> doing this would be to use an exception/condition to express a lack of
> total order, another would be to return something other than -1, 0, 1 from
> the compare procedure (perhaps return +nan.0), which would violate the
> conditions for a compare procedure according to this module as specified so
> far. I'm not sure what the best way to do this is, except to provide
> additional procedures for floating-point numbers, and not handle partial
> orders in a general way. My intuition tells me that a general approach
> would be more valuable in the long term, than to special case floats.
> Treating any and all partial orders that come along as special cases, just
> seems wrong to me.

SRFI 114 does provide a special case for floats.  What would be other
use cases for partial orders in general?

> Issues with "Comparison syntax":
> (if3) and (if**?) don't have a comparator parameter!

That's true; they are inherited directly from SRFI 67.  Perhaps they should
only accept comparators rather than compare procedures, or perhaps both.
What do you think?

> Issues with "Comparison procedures":
> The (not=?) procedure should be removed, there is a long history of
> omitting it.

That's because Scheme ordering predicates are multi-argument, and "not equals"
cannot be implemented in O(n); it requires O(n log n).  That does not matter
when only two arguments are permitted.

> All (**?) procedures should be removed.
> All (chain**?) procedures should be renamed to (**?).
> All (**?) procedures: [(<?), (<=?), (=?), (>?), (>=?)] should have 2 or
> more parameters, as (chain**?) does now.

If that were to be done, it would be impossible to allow the comparator
argument to default, because (=? comparator1 comparator2 comparator3)
would be ambiguous between comparing all three arguments for equality
using the default comparator, or comparating comparator2 and comparator3
for equality using comparator1.  I think that not being allowed to default the
comparator in the common 2-operand and 3-operand cases would be a loss.

> All (**/**?) procedures: [(</<=?), (>/>=?), (<=/<?), (>=/>?)] should have
> exactly 4 parameters, as they do now.
> The (</<?) procedure should be removed, it is the same as the new (<?).
> The (<=/<=?) procedure should be removed, it is the same as the new (<=?).
> The (>/>?) procedure should be removed, it is the same as the new (>?).
> The (>=/>=?) procedure should be removed, it is the same as the new (>=?).

The current draft renames the <-based ones using interval language
(open, closed, open-closed, closed-open) and drops the >-based ones.

John Cowan        http://www.ccil.org/~cowan          cowan@xxxxxxxx
Please leave your values                Check your assumptions.  In fact,
   at the front desk.                      check your assumptions at the door.
     --sign in Paris hotel                   --Cordelia Vorkosigan