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. 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.
Carl Eastlund On Thu, Apr 11, 2013 at 11:33 AM, Eli Barzilay <e...@barzilay.org> wrote: > OK, that's a valid use case -- but isn't it better for both of these > uses to just use some combinator for arities that generates a properly > normalized arity instead of constructing lists and explicitly > normalizing them? > > It's just that the interface looks very complex now. Some obvious > things: > > * `procedure-arity-includes?' vs `arity-includes?' > (but it's the second that compares two procedures... I'd just make > the first accept a procedure to avoid this unfortunate naming.) > > * `normalize-arity', `normalized-arity?', `arity=?' > (go away with a combinator, the last one gets replaced with > `equal?') > > > > A few minutes ago, Carl Eastlund wrote: > > If we want people to be able to create higher-order functions with > > precise arities via procedure-reduce-arity, for instance, we need to > > provide tools for manipulating arity values. Manipulating them is > > also useful for producing error messages that describe the arity of > > procedure values. I don't see any reason to close this stuff off, > > when it's the one useful, non-opaque aspect of procedure values. > > > > Carl Eastlund > > > > On Thu, Apr 11, 2013 at 11:13 AM, Eli Barzilay <e...@barzilay.org> wrote: > > > > Is there a real need to make this whole thing a public interface? > I'd > > think that a general direction is to move away from making it public > > (ie, remove the ability to create an arity value), and this seems to > > add a pretty big chunk of stuff in the opposite direction. > > > > About two weeks ago, c...@racket-lang.org wrote: > > > cce has updated `master' from 6e40caa7e2 to df00bbb194. > > > http://git.racket-lang.org/plt/6e40caa7e2..df00bbb194 > > > > > > =====[ 7 Commits > ]====================================================== > > > Directory summary: > > > 21.0% collects/racket/private/ > > > 21.5% collects/racket/ > > > 26.4% collects/scribblings/reference/ > > > 30.9% collects/tests/racket/ > > > > > > ~~~~~~~~~~ > > > > > > 59b1e32 Carl Eastlund <c...@racket-lang.org> 2013-03-30 11:45 > > > : > > > | Changed normalize-arity to coalesce arity-at-least with adjacent > > numbers. > > > | > > > | For instance, (normalize-arity (list 1 (arity-at-least 2))) now > > produces > > > | (arity-at-least 1). The implementation and the tests for > > normalize-arity both > > > | reflect this change. The randomized tests now also check that > the > > output > > > | represents the same arity as the input. > > > : > > > M collects/racket/private/norm-arity.rkt | 82 > +++++++++++++--------- > > > M collects/tests/racket/basic.rktl | 112 > > +++++++++++++++++++++++++----- > > > > > > ~~~~~~~~~~ > > > > > > e356c66 Carl Eastlund <c...@racket-lang.org> 2013-03-30 11:49 > > > : > > > | Re-provide normalize-arity from racket/function. > > > : > > > M collects/racket/function.rkt | 4 ++-- > > > > > > ~~~~~~~~~~ > > > > > > 4dd011a Carl Eastlund <c...@racket-lang.org> 2013-03-30 15:49 > > > : > > > | Added documentation for normalize-arity. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 42 > > ++++++++++++++++++---- > > > > > > ~~~~~~~~~~ > > > > > > 636f8a9 Carl Eastlund <c...@racket-lang.org> 2013-03-30 21:04 > > > : > > > | Moved normalized-arity?, arity=?, and arity-includes? into > racket/ > > function. > > > : > > > M collects/racket/function.rkt | 94 > > +++++++++++++++++++++++++++++++++++- > > > M collects/tests/racket/basic.rktl | 96 > > +------------------------------------ > > > > > > ~~~~~~~~~~ > > > > > > aaa99d5 Carl Eastlund <c...@racket-lang.org> 2013-03-30 21:05 > > > : > > > | Documented normalized-arity?, arity=?, and arity-includes?. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 87 > > +++++++++++++++++++--- > > > > > > ~~~~~~~~~~ > > > > > > f509420 Carl Eastlund <c...@racket-lang.org> 2013-03-30 17:12 > > > : > > > | Removed unnecessary duplication of normalize-arity. > > > : > > > M collects/tests/racket/fixnum.rktl | 21 ++------------------- > > > > > > ~~~~~~~~~~ > > > > > > df00bbb Carl Eastlund <c...@racket-lang.org> 2013-03-31 10:34 > > > : > > > | Updated contracts for arity-related functions. > > > | > > > | Added contract checking to arity=?, arity-includes?, and > > normalized-arity. > > > | Removed contract checking from normalize-arity to make it a total > > predicate. > > > | Updated documentation for normalize-arity to reflect this change. > > > : > > > M collects/racket/function.rkt | 21 > > ++++++++++++++++----- > > > M collects/racket/private/norm-arity.rkt | 2 ++ > > > M collects/scribblings/reference/procedures.scrbl | 13 > ++++++------- > > > > -- > > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > > http://barzilay.org/ Maze is > Life! > > > > -- > ((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
