My thoughts so far: 1. It always troubled me that filter, when written in the most natural way, had a "hang on to the head" problem when skipping over large numbers of items. I think this is something worth solving, and I'm glad that while developing the lazier branch, you came up with a compiler enhancement to address this. In my mind, this may be the most valuable aspect of the new changes. The new version of filter is definitely more complex than the old version, but it's not too bad. If the compiler enhancement could be backported to make the old (most natural) version work as well, I think that would be even better.
2. I definitely prefer that you go with the best names, rather than worrying about backward compatibility at this point. So I like the idea of changing the meaning of rest. I'm not particularly keen on the name "next", but I don't care that much. I feel fairly certain that my own personal programming style will be to stick with first/rest, and I doubt I'll use "next", so to me the name choice only matters to the extent that it uses up a name that might be natural in another context. 3. As I've noted here previously, I never cared much for nil punning, and I always try to write my own code in a way that doesn't rely on it. So I don't care if it goes away. 4. The new model is definitely more complicated to understand than the previous model. There was already a certain degree of mental overlap between collections and the seq interface. Now, there is also the subtle distinction between a seq and a sequence. rest and next are very similar, but one can return something empty, and one can return nil. Making the right choice, and interfacing with other code is now a bit more complicated (although people can always call seq to convert it into the seq/nil paradigm with certainty, which is not much different than before). I think the additional complexity is worth it to solve things like the filter problem, but I think it's definitely more confusing than before. 5. At first glance, it seems like sticking with the original lazy-cons model, but removing nil punning and adding an empty sequence sentinel, along with your compiler enhancement, would accomplish everything the new "lazier" branch accomplishes with much less mental complexity and subtle overlap, and resulting in the most intuitive version of filter working as expected. I know you like the seq/nil model, and the nil punning, but since you're already moving in the direction of reducing reliance on this approach, I hope you've considered going "all the way", to see if it would solve the problem more elegantly. If you have considered this already, I'd be curious to know whether it didn't solve the problem, or whether it just resulted in too much breakage with existing code, or whether it's just a style you don't like as a matter of taste... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
