[racket] arity of + versus <=

On Fri, Oct 28, 2011 at 12:55 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> On Fri, Oct 28, 2011 at 12:53 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> On Fri, Oct 28, 2011 at 11:44 AM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>>> On Fri, Oct 28, 2011 at 12:07 PM, John Clements
>>> <clements at brinckerhoff.org> wrote:
>>>>
>>>> On Oct 28, 2011, at 8:12 AM, Joe Marshall wrote:
>>>>
>>>>> On Wed, Oct 26, 2011 at 8:32 PM, Dan Grossman <djg at cs.washington.edu> wrote:
>>>>>> Very minor point, but is there a rationale beyond historical precedent
>>>>>> for + and * to allow any number of arguments but, =, <=, <, >, >= to
>>>>>> require at least two arguments?
>>>>>
>>>>> 0 is the additive identity. 1 is the multiplicative identity.
>>>>> What is the equality identity?
>>>>
>>>> No, I don't buy that. operators in \alpha X \alpha -> \beta can never have identities, but that doesn't mean they can't be generalized.
>>>>
>>>> I can definitely imagine that you would choose to disallow unary use of comparison operations to prevent a certain class of programming errors, but it seems pretty clear to me that the generalization of, e.g., <= is "is every sequential pair of items in the argument list related by the given operator."
>>>>
>>>> Am I missing something here?
>>>>
>>>> John
>>>
>>> Furthermore, that generalization is useful, as it makes (apply <= xs)
>>> into a simple implementation of "is xs monotonically non-decreasing?",
>>> just as (apply + xs) implements "the sum of the elements of xs".  If
>>> <= must accept 2 or more arguments (or even 1 or more), that does not
>>> work for all lists.  Personally, I'd prefer if <= and friends were
>>> generalized.  It seems more in tune with Racket's permissive Scheme
>>> heritage -- if append accepts "improper" lists, + mixes precise
>>> numbers with floating point, and all values act as booleans, why can't
>>> <= accept 0 or 1 arguments?
>>
>> Does this rationale also suggest that it is fine that (cdr '()) = '()?
>>
>> Robby
>
> No.  I don't see any sense in which that's a generalization of cdr.

The "any" there is probably too strong.  "Any" is an extremely broad
term.  How about "a sufficiently complete" sense.

> In fact it's quite non-uniform; for instance, applying cdr to a
> non-empty list produces a list one shorter.  If we want to extend cdr
> to length 0 lists, we need to somehow produce a list of length -1.  We
> restrict cdr from empty lists precisely because it can't be
> generalized.  Or at least that's how I see it.
>
> --Carl