Re: [Scheme-reports] R7RS-large comparators

[John Cowan <cowan@x>]

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

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports