Re: [racket-dev] how to define a custom "null" in typed racket
On Thu, Apr 11, 2013 at 6:47 PM, Eric Dobson wrote: > You shouldn't be able to send the TR into an inifinite loop. > Typechecking is supposed to terminate. Please try to reduce it to the > minimum testcase and file a bug. I just filed pr 13687. > > On Thu, Apr 11, 2013 at 3:32 PM, Danny Yoo wrote: >> Perhaps something like this? >> >> >> ; >> #lang typed/racket/base >> >> (provide mynull mycar mycdr) >> >> (struct: MyNull ()) >> (define mynull (MyNull)) >> >> (define-type MyListof (All (A) (Rec X (U MyNull (Pair A X) >> >> (: mycar : (All (A) ((MyListof A) -> A))) >> (define (mycar lst) >> (if (MyNull? lst) >> (error 'mycar "given list is empty") >> (car lst))) >> >> (: mycdr : (All (A) ((MyListof A) -> (MyListof A >> (define (mycdr lst) >> (if (MyNull? lst) >> (error 'mycdr "given list is empty") >> (cdr lst))) >> ; >> >> where mynull is the singleton instance of the opaque structure type MyNull. >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] how to define a custom "null" in typed racket
You shouldn't be able to send the TR into an inifinite loop. Typechecking is supposed to terminate. Please try to reduce it to the minimum testcase and file a bug. On Thu, Apr 11, 2013 at 3:32 PM, Danny Yoo wrote: > Perhaps something like this? > > > ; > #lang typed/racket/base > > (provide mynull mycar mycdr) > > (struct: MyNull ()) > (define mynull (MyNull)) > > (define-type MyListof (All (A) (Rec X (U MyNull (Pair A X) > > (: mycar : (All (A) ((MyListof A) -> A))) > (define (mycar lst) > (if (MyNull? lst) > (error 'mycar "given list is empty") > (car lst))) > > (: mycdr : (All (A) ((MyListof A) -> (MyListof A > (define (mycdr lst) > (if (MyNull? lst) > (error 'mycdr "given list is empty") > (cdr lst))) > ; > > where mynull is the singleton instance of the opaque structure type MyNull. > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] how to define a custom "null" in typed racket
Perhaps something like this? ; #lang typed/racket/base (provide mynull mycar mycdr) (struct: MyNull ()) (define mynull (MyNull)) (define-type MyListof (All (A) (Rec X (U MyNull (Pair A X) (: mycar : (All (A) ((MyListof A) -> A))) (define (mycar lst) (if (MyNull? lst) (error 'mycar "given list is empty") (car lst))) (: mycdr : (All (A) ((MyListof A) -> (MyListof A (define (mycdr lst) (if (MyNull? lst) (error 'mycdr "given list is empty") (cdr lst))) ; where mynull is the singleton instance of the opaque structure type MyNull. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] how to define a custom "null" in typed racket
I know the code below is wrong because it sends TR into an infinite loop. What is the recommended way to represent mynull (and its type) without leaking its representation to a user of this library? #lang typed/racket (define mynull null) (define-type MyListof (All (A) (Rec X (U mynull (Pair A X) (: mynull? : (All (A) ((MyListof A) -> Boolean))) (define (mynull? lst) (null? lst)) (: mycar : (All (A) ((MyListof A) -> A))) (define (mycar lst) (if (mynull? lst) (error 'mycar "given list is empty") (car lst))) (: mycdr : (All (A) ((MyListof A) -> (MyListof A (define (mycdr lst) (if (mynull? lst) (error 'mycdr "given list is empty") (cdr lst))) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] take/drop argument order
At Thu, 11 Apr 2013 15:20:54 -0400, Eli Barzilay wrote: > In any case, given that nobody seems sufficiently interested, maybe > it's best to remove the new functions for this release to avoid code > depending on it which will make later changes more difficult? I don't think we're going to have any great new ideas. How about leaving them as they are, which is maybe the best compromise we'll find for `racket', and start work on `racket2'? With respect to the conventions of argument order and names, maybe we could have the rule that a function whose name is `X-' takes its X first (and that would be the common case), while functions that do not take the X first simply don't start with `X-'. In that view, the current `map' is not short for `list-map'; it's short for `map-lists'. Similarly, `vector-map' should have been called `map-vectors'. The `list-ref' and `vector-ref' functions are correctly named. The `hash-map' function is also correctly named, although some would prefer that we had `map-hash'; we could have both. Of course, for `racket2', `map' should be short for `map-sequences', not `map-lists', and so on. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] take/drop argument order
An hour ago, Asumu Takikawa wrote: > On 2013-04-11 12:05:59 -0400, Eli Barzilay wrote: > > Remove the `*f' functions from the interface, and change the > > non-`*f' functions to accept keywords as follows: > > > > (take #:num N L) > > (take #:while P L) > > (take #:until P L) > > I like this suggestion since keywords seem like a nice Rackety > solution. > > On the other hand, does this solve the original problem? As I > understand, the original objection was that the `take` arguments > should look familiar to someone from Clojure, Haskell, etc. Yeah, you're right. Maybe do the overloading either-order thing in addition to the keywords? The main problem that it solves then is the many bindings. In any case, given that nobody seems sufficiently interested, maybe it's best to remove the new functions for this release to avoid code depending on it which will make later changes more difficult? > Also, what happens if I wrote the following? > > (take #:while P L 5) That would do the same as specifying both `#:while' and `#:until', which is most likely an error. (Although it might be a combination of all of the conditions, but that seems like an overkill generalization.) -- ((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
Re: [racket-dev] take/drop argument order
On 2013-04-11 12:05:59 -0400, Eli Barzilay wrote: > Remove the `*f' functions from the interface, and change the > non-`*f' functions to accept keywords as follows: > > (take #:num N L) > (take #:while P L) > (take #:until P L) I like this suggestion since keywords seem like a nice Rackety solution. On the other hand, does this solve the original problem? As I understand, the original objection was that the `take` arguments should look familiar to someone from Clojure, Haskell, etc. Also, what happens if I wrote the following? (take #:while P L 5) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26536: master branch updated
On Thu, Apr 11, 2013 at 10:54 AM, Eli Barzilay 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
Re: [racket-dev] take/drop argument order
Revised suggestion which I think can address both reducing the number of functions and the argument order: Remove the `*f' functions from the interface, and change the non-`*f' functions to accept keywords as follows: (take #:num N L) (take #:while P L) (take #:until P L) etc while keeping the current arguments as a compatibility feature. Another possibility is adding a `#:from-end' keyword for the `*-right' variants (and keep the existing ones for compatibility). 50 minutes ago, Eli Barzilay wrote: > About two weeks ago, Asumu Takikawa wrote: > > Late reply, but better than never. > > > > On 2013-03-10 16:20:14 -0400, Eli Barzilay wrote: > > > Assuming this, here's a suggestion that I made in the past for > > > resolving this: > > > > > > * Make the existing `take', `drop', `split-at' accept their arguments > > > in *either* order. > > > > I'm fine with this. > > I think that there was one objection -- so additional opinions will be > good at this point, before a release with the new functions. > > > > > > > * Change the required types for lists to be a null-or-pair, or > > > even require a `list?', or require a `list?' but throw an error > > > only if scanning gets to a non-null-terminator. Any of these > > > would make sure that the arguments are distinguishable. (You > > > can currently write something like (take 0 1) -- it's not an > > > error.) > > > > I would much prefer a `list?` if backwards compatibility for this > > isn't a concern. Has anyone *ever* used the "feature" that `take` > > can operate on non-lists? > > Probably not intentionally -- just code that isn't supposed to check > the list?-ness up-front. (But I still prefer forbidding it.) > > > > > * And another thing that can be done to reduce the name clutter is > > > to have only the plain names, but make them accept either an > > > index or a predicate. > > > > I'm less sure about this change, since the `f` suffix isn't > > particularly verbose and the integer case is likely more common, but > > I'm not opposed to it either. > > (It's not the verbosity that bothers me -- the short `f' practically > eliminates that. It's the fact that there are so many functions to > make the interface symmetric.) > > Again -- more opinions at this point would be good. -- ((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
Re: [racket-dev] [plt] Push #26536: master branch updated
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
Re: [racket-dev] [plt] Push #26536: master branch updated
We cannot get rid of procedure-arity-includes?, but we could make it accept either a procedure or an arity for both arguments. For the second bullet, I think that we'd run afoul of backwards compatibility problems. That is, there is code out there that currently builds and works with arities that are not normalized and we'd break it if we required all arity-accepting primitives to be given normalized arities. But maybe that's warranted? Robby On Thu, Apr 11, 2013 at 10:33 AM, Eli Barzilay 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 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 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 2013-03-30 11:49 > > > : > > > | Re-provide normalize-arity from racket/function. > > > : > > > M collects/racket/function.rkt | 4 ++-- > > > > > > ~~ > > > > > > 4dd011a Carl Eastlund 2013-03-30 15:49 > > > : > > > | Added documentation for normalize-arity. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 42 > > ++ > > > > > > ~~ > > > > > > 636f8a9 Carl Eastlund 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 2013-03-30 21:05 > > > : > > > | Documented normalized-arity?, arity=?, and arity-includes?. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 87 > > +++--- > > > > > > ~~ > > > > > > f509420 Carl Eastlund 2013-03-30 17:12 > > > : > > > | Removed unnecessary duplication of normalize-arity. > > > : > > > M collects/tests/racket/fixnum.rktl | 21 ++--- > > > > > > ~~ > > > > > > df00bbb Carl Eastlund 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 norm
Re: [racket-dev] [plt] Push #26536: master branch updated
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 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 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 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 2013-03-30 11:49 > > > : > > > | Re-provide normalize-arity from racket/function. > > > : > > > M collects/racket/function.rkt | 4 ++-- > > > > > > ~~ > > > > > > 4dd011a Carl Eastlund 2013-03-30 15:49 > > > : > > > | Added documentation for normalize-arity. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 42 > > ++ > > > > > > ~~ > > > > > > 636f8a9 Carl Eastlund 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 2013-03-30 21:05 > > > : > > > | Documented normalized-arity?, arity=?, and arity-includes?. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 87 > > +++--- > > > > > > ~~ > > > > > > f509420 Carl Eastlund 2013-03-30 17:12 > > > : > > > | Removed unnecessary duplication of normalize-arity. > > > : > > > M collects/tests/racket/fixnum.rktl | 21 ++--- >
Re: [racket-dev] [plt] Push #26536: master branch updated
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 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 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 2013-03-30 11:49 > > : > > | Re-provide normalize-arity from racket/function. > > : > > M collects/racket/function.rkt | 4 ++-- > > > > ~~ > > > > 4dd011a Carl Eastlund 2013-03-30 15:49 > > : > > | Added documentation for normalize-arity. > > : > > M collects/scribblings/reference/procedures.scrbl | 42 > ++ > > > > ~~ > > > > 636f8a9 Carl Eastlund 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 2013-03-30 21:05 > > : > > | Documented normalized-arity?, arity=?, and arity-includes?. > > : > > M collects/scribblings/reference/procedures.scrbl | 87 > +++--- > > > > ~~ > > > > f509420 Carl Eastlund 2013-03-30 17:12 > > : > > | Removed unnecessary duplication of normalize-arity. > > : > > M collects/tests/racket/fixnum.rktl | 21 ++--- > > > > ~~ > > > > df00bbb Carl Eastlund 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
Re: [racket-dev] [plt] Push #26536: master branch updated
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 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 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 2013-03-30 11:49 > > : > > | Re-provide normalize-arity from racket/function. > > : > > M collects/racket/function.rkt | 4 ++-- > > > > ~~ > > > > 4dd011a Carl Eastlund 2013-03-30 15:49 > > : > > | Added documentation for normalize-arity. > > : > > M collects/scribblings/reference/procedures.scrbl | 42 > ++ > > > > ~~ > > > > 636f8a9 Carl Eastlund 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 2013-03-30 21:05 > > : > > | Documented normalized-arity?, arity=?, and arity-includes?. > > : > > M collects/scribblings/reference/procedures.scrbl | 87 > +++--- > > > > ~~ > > > > f509420 Carl Eastlund 2013-03-30 17:12 > > : > > | Removed unnecessary duplication of normalize-arity. > > : > > M collects/tests/racket/fixnum.rktl | 21 ++--- > > > > ~~ > > > > df00bbb Carl Eastlund 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! > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26536: master branch updated
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 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 2013-03-30 11:49 > : > | Re-provide normalize-arity from racket/function. > : > M collects/racket/function.rkt | 4 ++-- > > ~~ > > 4dd011a Carl Eastlund 2013-03-30 15:49 > : > | Added documentation for normalize-arity. > : > M collects/scribblings/reference/procedures.scrbl | 42 > ++ > > ~~ > > 636f8a9 Carl Eastlund 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 2013-03-30 21:05 > : > | Documented normalized-arity?, arity=?, and arity-includes?. > : > M collects/scribblings/reference/procedures.scrbl | 87 > +++--- > > ~~ > > f509420 Carl Eastlund 2013-03-30 17:12 > : > | Removed unnecessary duplication of normalize-arity. > : > M collects/tests/racket/fixnum.rktl | 21 ++--- > > ~~ > > df00bbb Carl Eastlund 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! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] take/drop argument order
About two weeks ago, Asumu Takikawa wrote: > Late reply, but better than never. > > On 2013-03-10 16:20:14 -0400, Eli Barzilay wrote: > > Assuming this, here's a suggestion that I made in the past for > > resolving this: > > > > * Make the existing `take', `drop', `split-at' accept their arguments > > in *either* order. > > I'm fine with this. I think that there was one objection -- so additional opinions will be good at this point, before a release with the new functions. > > * Change the required types for lists to be a null-or-pair, or > > even require a `list?', or require a `list?' but throw an error > > only if scanning gets to a non-null-terminator. Any of these > > would make sure that the arguments are distinguishable. (You > > can currently write something like (take 0 1) -- it's not an > > error.) > > I would much prefer a `list?` if backwards compatibility for this > isn't a concern. Has anyone *ever* used the "feature" that `take` > can operate on non-lists? Probably not intentionally -- just code that isn't supposed to check the list?-ness up-front. (But I still prefer forbidding it.) > > * And another thing that can be done to reduce the name clutter is > > to have only the plain names, but make them accept either an > > index or a predicate. > > I'm less sure about this change, since the `f` suffix isn't > particularly verbose and the integer case is likely more common, but > I'm not opposed to it either. (It's not the verbosity that bothers me -- the short `f' practically eliminates that. It's the fact that there are so many functions to make the interface symmetric.) Again -- more opinions at this point would be good. -- ((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
