Mark and Mike you fail to address my deeper question. I've been using many different Clojure libraries all day long with the latest equals branch. Guess what?
No loop/recur bugs. When you guys start postIng your broken code that has this problem then people can start believing it is an issue for working code. Until then this is just theoretical rhetoric. On Saturday, June 19, 2010, Mark Engelberg <mark.engelb...@gmail.com> wrote: > On Sat, Jun 19, 2010 at 5:13 PM, David Nolen <dnolen.li...@gmail.com> wrote: >> Huh? That doesn't look like it's going to work at all. >> 1) 1 is primitive, we know that, accept it >> 2) we don't know the type of n, what will (* r n) be? >> 3) BOOM! > > Yes David, if you have a deep understanding of how loop/recur > interacts with primitives, and you understand that n, as an input is > boxed and that literals are primitives, it is of course possible to do > the analysis and see why it doesn't work. > > But it does look like it *should* work -- in current Clojure it works, > and the same kind of code in just about any dynamically typed language > I can think of would work. It might not work in a statically typed > language, but the types would be right there in your face, so it would > be totally obvious what was going on. The problem is that the > behavior is dependent on something that is invisible from the code, > and requires considerable reasoning even for this simple example. > >> My suggestion is to stop it with the contrived examples. Start showing some >> real code, real problems in your real programs. Using loop/recur is already >> the beginning of code smell for anything that is not performance sensitive. > > I think the notion that loop/recur is a code smell for anything that > isn't performance sensitive is absurd. It's basically the only > looping mechanism that Clojure offers - it's in all types of code. > >> (defn fact >> ([n] (fact n 1)) >> ([n r] (if (zero? n) >> r >> (recur (dec n) (* r n))))) >> Sleep soundly. > > The fact that this refactoring of the fact function fixes the problem > further bolsters our argument that the newly proposed semantics are > significantly more inscrutable than they should be. Without a fair > amount of thought, it's completely unobvious why this refactoring > should fix the problem. (Yes, I know it's because it boxes the 1 when > it passes it to the two-arg version, but stuff like this really > shouldn't make such a significant difference in behavior). > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > 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 -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
