On Fri, Oct 28, 2011 at 12:55 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: > On Fri, Oct 28, 2011 at 12:53 PM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: >> On Fri, Oct 28, 2011 at 11:44 AM, Carl Eastlund <c...@ccs.neu.edu> wrote: >>> On Fri, Oct 28, 2011 at 12:07 PM, John Clements >>> <cleme...@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 <d...@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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
