Ken Dickey wrote: > Personally, I think that a mismatch between the expected number of > "arguments" > to a continuation is like a mismatch to the number of arguments to a function > call -- it should raise an exception to alert the system/programmer that > there is a problem. > > I see the "less than 2 arguments" comparison case in the same way. I.e. my > personal preference is that an exception be raised. [This is a different > question than "What would a sensible result be in such a case?".] > > Can the argument be made that there is a usage case for arithmetic > comparisons > with less than two arguments which has a sensible result? Where would this > lead? > >
A piece of equipment takes some number of measurements in a given period of time, T. The numeric values of the measurements should be monotonic. The number of measurements during T is greater than or equal to 0. If they are not monotonic, the procedure EMERGENCY-HALT-ENGINE should be called. That's a case when it is *natural* to want arbitrary-arity comparison functions. But next: Commonly we assemble equipment that takes 0 or more measurements in a given T where we have some predictate P, that accepts 0 or more measurements and returns #t iff we should call EMERGENCY-HALT-ENGINE. Useful predicates include "all the measurements have a sum which is non-negative" and "all of the measurements are prime numbers". That's a whole family of cases of which the more flexible arity versions of ordering predicates are useful. In general, deciding that an ordering predicate "expects" two or more arguments expresses an expectation that is kind of arbitrary relative to the simplest accounts of the underlying domains. It is an "arbitrary restriction," allegedly for the programmer's own good: precisely the kind of thing we're taught to avoid. Of course, you can make use cases where you want to capture the abstraction of an engine-halt test that uses predicates of only arity 2 or more. Or only of arity 3 or more. Etc. To that we would observe that 0 is the simplest number and that it is easier to describe how to restrict 0 to 2 than vice versa. (And that's another good argument for 0-arity comparisons: Without them, you have to write new code to state the meaning of 0-argument calls. With them, the worst you have to do is write new code to prevent 0-argument calls.) -t _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
