On Thu, Apr 11, 2013 at 10:54 AM, Eli Barzilay <e...@barzilay.org> wrote:
> A few minutes ago, Carl Eastlund wrote: > > If you're writing a higher-order tool like curry or negate, and want to > > produce a meaningful arity for its result, you're going to need some > explicit > > representation of arity to manipulate, e.g. subtract one from every > number in > > the list after partially applying to a single argument. Once users are > > manipulating the value, you either need to accept non-normalized inputs, > or > > you need an abstract datatype to encapsulate the whole thing that > enforces > > normalization. Since we already have list-based arities in our > interfaces, I > > continued with the interface as it was. > > OK, I'll settle this with this addition to the racket2 wishlist: > > * Get rid of the `arity-at-least` struct, and replace it with just > an `arity` that abstracts over the whole arity thing -- always > normalizing and includes keyword arity information. > > > That sounds perfect to me! > > I did think of combining the two arity-includes? functions, I wasn't > > sure whether the extra overloading would make things clearer or more > > confused. I can see doing it either way. > > +1 for the overloading, given the bad names that result from not doing > so. Meanwhile, I've added this to the above item: > > Also, make it possible to always use a procedure where an arity is > expected. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
