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
