Re: [racket-dev] `take' argument order
About a minute ago, Robby Findler wrote: Just on general principle, I think that making take in lazy match take in regular racket is more important than matching Haskell, but I don't really have a firm enough grasp on the details to have a strong opinion either way on the below. [Yes, that's true regardless. If `take' in plain `racket' stays as is, then eventually the one in lazy will need to change. It just happened to be the first thing that made me look at the order more closely, and discover thet other issues. As another point, the justification for the argument order in Haskell is not laziness but its implicit currying -- so of course it shouldn't be a reason to make lazy racket follow it.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
10 minutes ago, Robby Findler wrote: On Wed, Jun 8, 2011 at 8:55 AM, Eli Barzilay e...@barzilay.org wrote: [Yes, that's true regardless. If `take' in plain `racket' stays as is, then eventually the one in lazy will need to change. It just happened to be the first thing that made me look at the order more closely, and discover thet other issues. As another point, the justification for the argument order in Haskell is not laziness but its implicit currying -- so of course it shouldn't be a reason to make lazy racket follow it.] So, part of the discussion is changing the argument order for strict Racket's take? Yes. The problem is that `racket/list' followed srfi-1 which contradicts Haskell, and Clojure (and very likely more), *and* it also contradicts its own `take-while': (take list n) (take-while pred list) That seems difficult, for backward compatibility reasons. My suggestion, to accommodate legacy code, is to allow *both* orders, which is possible if improper lists are forbidden. (I said that I'm fine with just changing it, but the compatibility issue is probably making that impractical.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
I like the current order of `take' because it's consistent with Racket's dominant convention. To the list of advantages, I would add consistent with `take' in SRFI-1. It seems strange to make `take' less compatible with SRFI-1's `take' toward the end of making `take' be more compatible with SRFI-1's `take-while'. Global consistency (not to mention backward compatibility) seems better served by being incompatible with SRFI-1's `take-while'. At Wed, 8 Jun 2011 09:36:50 -0400, Eli Barzilay wrote: So ... no objections to this? Yesterday, Eli Barzilay wrote: While trying to finally get `take-while' etc, I realized that the problem with the `take' (and `drop' and related) argument order is even more thorny. The existing problem is that `take' in lazy takes the number first and then the list -- not a big problem by itself, but: * Contradicts Haskell's argument order * Contradicts Clojure's argument order * *And* contradicts srfi-1's argument order for `take-while', which takes the predicate first So how about making it take its inputs in any order? (Possibly deprecating the number-last in the docs and eventually removing it.) No need to start a flamewar -- I know why it would be bad. But the above mess and potential confusion seems big enough to outweigh it. Specifically, it seems to me very odd now to go with the srfi-1 ordering for `take-while' and friends. (I'm also fine with swapping the arguments completely, but it seems that the breakage makes it a bad change.) To make things balanced -- * I see two arguments for keeping the order as it is now: (a) it makes it more like `list-ref' etc, where the number comes last (potential solution if the above is acceptable: make it do the same too, or just admit that indexing is different from these things); and (b) it accomodates better a potential future (list-slice l from too) which would look odd with the from-too arguments before the list. * OTOH, the advantages of the number-first order are being compatible with the rest of the world, and an order that is uniformly used in `take-while' etc. Opinions? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
Three minutes ago, Matthew Flatt wrote: I like the current order of `take' because it's consistent with Racket's dominant convention. To the list of advantages, I would add consistent with `take' in SRFI-1. (Yeah, that was implicit in the original reason...) It seems strange to make `take' less compatible with SRFI-1's `take' toward the end of making `take' be more compatible with SRFI-1's `take-while'. Global consistency (not to mention backward compatibility) seems better served by being incompatible with SRFI-1's `take-while'. I'm slightly more concerned about compatibility with other languages, which also sounds odd, but has been a source of confusion. In any case, I do take compatibility as a priority, so I'm suggesting allowing both orders for this case. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
A few seconds ago, Matthew Flatt wrote: At Wed, 8 Jun 2011 10:21:18 -0400, Eli Barzilay wrote: In any case, I do take compatibility as a priority, so I'm suggesting allowing both orders for this case. You also mentioned disallowing improper lists as a related change, which could be significant. Actually that's not needed -- the only possibly ambiguous case is two integers, and in that case it could go with the srfi-1 order. (Which would make it ugly, and I thought that diverging from srfi-1 on improper lists is better, since racket already diverges on other srfi-1 things.) I'd much rather leave this alone and spend time elsewhere. OK. And since I'll probably do `take-while' etc very soon -- I'll go with the (self-inconsistent) srfi-1 order. Unless someone has an objection to that? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
On Wed, Jun 8, 2011 at 9:21 AM, Eli Barzilay e...@barzilay.org wrote: In any case, I do take compatibility as a priority, so I'm suggesting allowing both orders for this case. I did not mention this (remaining silent in response to your comment with the word 'flame' in the original message), but I am strongly against this choice. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
10 minutes ago, Robby Findler wrote: On Wed, Jun 8, 2011 at 9:21 AM, Eli Barzilay e...@barzilay.org wrote: In any case, I do take compatibility as a priority, so I'm suggesting allowing both orders for this case. I did not mention this (remaining silent in response to your comment with the word 'flame' in the original message), but I am strongly against this choice. (Well, I didn't want flames, but I did want to hear +1s and -1s.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
6 minutes ago, Stephen Bloch wrote: On Jun 8, 2011, at 9:55 AM, Eli Barzilay wrote: ... the justification for the argument order in Haskell is not laziness but its implicit currying -- so of course it shouldn't be a reason to make lazy racket follow it.] Another justification for Haskell's argument order is compatibility with English: take 5 primes makes a lot more sense than take primes 5. It could be argued that compatibility with English is even more important than compatibility with Clojure, or Haskell, or SRFI/1, or racket/typed That counters a lot of existing racket functions (`list-ref' vs the nth element of), and worse -- it contradicts some uniformity (if you follow English, then `for-each' should not have the same order as `map'). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take-until' etc
Me too. I like `take-until' as well. 2011/6/8 Jay McCarthy jay.mccar...@gmail.com: I'd really like #:unless as well iPhoneから送信 On 2011/06/08, at 9:21, Eli Barzilay e...@barzilay.org wrote: Anyone seconds this? And if so, then maybe for-loops should have an `#:unless' too? (I know that this was raised, but now there's more experience using it.) Yesterday, Jay McCarthy wrote: I've used them before and I find they read better than using negate. 2011/6/7 Eli Barzilay e...@barzilay.org: Does anyone see a need for `take-until' (and `drop-' and `-right' versions), or is `negate' enough to not have that? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
At Wed, 8 Jun 2011 10:15:58 -0500, Robby Findler wrote: On Wed, Jun 8, 2011 at 9:21 AM, Eli Barzilay e...@barzilay.org wrote: In any case, I do take compatibility as a priority, so I'm suggesting allowing both orders for this case. I did not mention this (remaining silent in response to your comment with the word 'flame' in the original message), but I am strongly against this choice. +1 Allowing both orders sounds like it would lead to a lot of confusion and make code harder to read. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `take' argument order
Take from the sequence of primes the first five numbers and add them up. This is at most slightly mangled :-) On Jun 8, 2011, at 11:38 AM, Eli Barzilay wrote: 6 minutes ago, Stephen Bloch wrote: On Jun 8, 2011, at 9:55 AM, Eli Barzilay wrote: ... the justification for the argument order in Haskell is not laziness but its implicit currying -- so of course it shouldn't be a reason to make lazy racket follow it.] Another justification for Haskell's argument order is compatibility with English: take 5 primes makes a lot more sense than take primes 5. It could be argued that compatibility with English is even more important than compatibility with Clojure, or Haskell, or SRFI/1, or racket/typed That counters a lot of existing racket functions (`list-ref' vs the nth element of), and worse -- it contradicts some uniformity (if you follow English, then `for-each' should not have the same order as `map'). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
