[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] R7RS-large comparators
Andrew Robbins scripsit:
> This is a comment about
> I noticed some issues and should like to make comments about this possible
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