Hello, The way I think about it is "am I in a portion of code that does "pure functional stuff", or am I doing side effects ? A "pure functional stuff" resembles a computation, but not the storage part, or the part that gets the stuff from the outside (that is, no input / output stuff).
"doing side effects" is when your function not only responds to a call to it by reading its input data and computing a new one that it returns, but also when it reads the input data, does some stuff to change the "world" (by accessing functions that will permanently change the world), and also (maybe) return a value. In this case, generally, comes with the "non pure" stuff the need to control the flow of execution of your program. That is : function A must be called before function B, and the effects of A on the "world" must have been realized before function B can run. In your case, you're calling add-watch which is clearly (to me) a side-effect function because it adds watchers to a long list of watchees by modifying them "in place" (side-effect). Generally speaking, if this talk about "side-effect free function" is still a little bit unclear to you, here are some smells to guess if a given function is "pure" or not : - does the function return a value (different from nil) ? If no -> probably a function with side effect .. or a function that really does nothing ! - does the function return newly computed values ? If no -> probably a function with side effect .. or a function that really does nothing ! (please note that the inverse is not true : you can't say that a function is pure just because it returns a new computed value of something) I would like to add a third rule to this list, but currently you will not encounter it for a lot of cases, yet it is correct in a number of case and I think it applies correctly to those cases : - does the function implementation use calls to functions ending with a ! ( e.g. set!) : those functions are performing side effects by permanently changing the value of something in the "world". HTH, -- Laurent 2009/3/2 max3000 <maxime.lar...@gmail.com> > > Hi, > > I find the laziness in clojure very hard to wrap my head around. I > understand the idea and it's probably nice in theory. However, in real > life it doesn't seem really useful beyond hardcore mathematical > problems. > > Case in point, I just spent 2 hours debugging a piece of code (shown > below) that seemed simple enough. This is the 3rd time this week that > I've lost substantial time to laziness. I'm pretty pissed to tell the > truth and I find myself wrapping things in doseq more and more just to > be sure. I rarely use 'for' anymore, what's the point? > > Here is the code that gave me trouble: > > (map #(add-watch % watcher callback-fn) all-agents) > > This was not executing. I had to change it to the below expression: > > (doseq [agent all-labor-agents] > (add-watch agent total-labor-agent callback-fn)) > > This second expression seems less elegant than the map above. Why > doesn't clojure realize that an add-watch really should actually loop > over all-agents? Why is it that Java calls are not made in similar > expressions? > > Is laziness so useful that we should waste time investigating and > fixing errors like this? Sure, there could be special constructs for > laziness when we really need it. However, clojure shouldn't default to > it IMO. At this point, laziness is a nice concept but it feels > somewhat removed from reality to tell the truth. Of course I want to > iterate over my collection when I'm doing an add-watch! > > What am I missing? > > Thanks, > > Max > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
