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.
> 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
