Re: [Scheme-reports] R7RS-large comparators John Cowan 12 Jul 2013 14:58 UTC
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@srfi.schemers.org>. 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 xxxxxx@ccil.org 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