I'd vote for the breaking changes. We don't have so much code written that it cannot be fixed. However, this depends on the book in production. Having _Programming Clojure_ come out with incompatible code would be a big blow, I think.
On Mon, Feb 16, 2009 at 9:22 AM, Mibu <mibu.cloj...@gmail.com> wrote: > > I'm all for breaking bad habits and names and I love it that you give > good design considerations precedence over heritage, but here I think > using the first/rest/next combo is confusing, and will continue to be > confusing in the long-term. > > rest is expected to be a sequence by Lispers, and next is expected to > be an item by Java-ers. Both are universally recognized as such and > are frequently used. The semantics given to them by their common use > in computing (and especially in CS education) supersedes their > semantics in daily English or the semantics which should have been > most appropriate to them if their semantics were defined today first. > > Synonyms are also not a problem as they receive their unique semantics > soon enough if they are regularly used, and if they're not then there > is no need to waste of good short word on them. I'm against more > because it evokes the semantics of the more? predicate but maybe first/ > remaining/rest or instead of remaining: rest-collection, rest-coll, or > restc. > > I seem to be in the minority about this... > > > On Feb 15, 7:18 pm, Rich Hickey <richhic...@gmail.com> wrote: > > I'm pretty much finished with the fully-lazy implementation and am > > happy so far with the results. I think this will be an important > > addition to Clojure and am planning to add it. > > > > Now comes the hard part - names and change. The essence of the fully > > lazy seqs is that they will not consume any resources, perform any > > computation or trigger any side effects until they are consumed. This > > is a change to the way the sequence functions work now, in that, in > > order to determine whether they should return a seq or nil, they need > > to touch at least one item. So, there will be an additional function > > on seqs, one that returns the items other than the first as a logical, > > non-nil, possibly empty collection. Calling seq on this collection > > will give you what rest currently gives you - the next seq object or > > nil if none. So the core operations on seqs will be: > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (possibly-empty-collection-of-the-remaining-items x) > > > > ;seq on next item, or nil if none > > (seq-on-the-next-item-if-any-else-nil x) > > > > (first x) is uncontroversial and won't change. The second is a new > > function. The third is currently called 'rest'. > > > > I have some ideas for names, and there are definitely tradeoffs > > between short-term pain and long-term goodness in some of the options. > > The first option is to leave rest alone, and give the new function a > > new name, like more. > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (more x) > > > > ;seq on next item, or nil if none > > (rest x) > > > > Note that (rest x) === (seq (more x)) > > > > This is implemented in the lazy branch, SVN rev 1281. It has the > > attribute of requiring the fewest changes to existing code, and the > > drawback of leaving us with less-than-ideal names, especially insofar > > as more (or whatever you choose to call it) will in some way seem > > synonymous with rest. This naming scheme, and the changes it implies, > > is documented here: > > > > http://clojure.org/lazier1 > > > > The second option is to choose the best possible names, and deal with > > some short term pain in porting and confusion. I think the best names > > are: > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (rest x) > > > > ;seq on next item, or nil if none > > (next x) > > > > This is implemented in the lazy branch, SVN rev 1282. Note that this > > changes the meaning of rest, and gives the current rest operation a > > new name, next. It has the attributes of using the most appropriate > > names (IMO) and the drawback of changing the semantics of a frequently > > used function name, but still offering that functionality under a > > different name. It would also break the compatibility of rest with > > Common Lisp's. As with the previous model, the third function can be > > defined in terms of the second - (next x) === (seq (rest x)). This > > naming scheme, and the changes it implies, is documented here: > > > > http://clojure.org/lazier > > > > A third option would be to retire rest and use only new names: > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (more x) > > > > ;seq on next item, or nil if none > > (next x) > > > > I haven't implemented this. > > > > I prefer first/rest/next. I think rest is the best complement to > > first, and it should mean the logical collection once things are fully > > lazy. I think next implies the next seq, as well as the eager nature > > of the operation. > > > > I am looking for feedback from people willing to read and understand > > the linked-to documentation and the fully lazy model, and especially > > from those trying the lazy branch code and porting some of your own. > > Questions on the model welcome as well. Chouser has also blogged a bit > > about this, with some useful descriptions of nil punning: > > > > http://blog.n01se.net/?p=39 > > > > I've been working on this for a few months, in lieu of more > > interesting things, because I knew it would be a breaking change and > > we're trying to get the biggest of those behind us. I appreciate any > > effort you spend in trying to provide informed input. > > > > Thanks, > > > > Rich > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
