RE: Side Effects What about logging? Without a debugger I use lots of print's to debug my code... and that often produces confusing results as things may not get evaluated in the order I expect.
For that matter, now that we have integrated Java debuggers, what does setting a breakpoint really mean? And what does it imply about the state of all the variables outside the current scope? How do others think about debugging lazy code? P Laurent PETIT wrote: > 2009/3/3 Mark Volkmann <r.mark.volkm...@gmail.com > <mailto:r.mark.volkm...@gmail.com>> > > > On Tue, Mar 3, 2009 at 9:12 AM, Laurent PETIT > <laurent.pe...@gmail.com <mailto:laurent.pe...@gmail.com>> wrote: > > Hello Mark, > > > > Just one point : > > > > 2009/3/3 Mark Volkmann <r.mark.volkm...@gmail.com > <mailto:r.mark.volkm...@gmail.com>> > >> > >> Does this seem like a good way to choose between doall, dorun, > doseq > >> and for to evaluate all the items in sequences? > >> > >> Ask these questions: > >> > >> Do you already have the lazy sequence in a variable or do you still > >> need to build it? > >> If you already have it, use dorun or doall. Otherwise use doseq > or for. > >> While code inside a dorun or doall could build the sequence, using > >> doseq and for are considered more idiomatic/readable. > >> Also, they provide list comprehension features such as > processing more > >> than one sequence and filtering with :when/:while. > >> > >> For example, instead of using the following to get a new sequence > >> where all the items are multiplied by two: > >> (doall (map #(* % 2) my-coll)) > >> use this: > >> (for [item my-coll] (* item 2)) > > > > I don't think it is a good example, since it conveys the idea > that it could > > be interesting to use doall or for for mapping a coll to > multiply its items. > > This example, in which there is no side effect at all in the > inner loop, is > > really typical of the use of map ! And forcing the sequence > there gives you > > nothing (?) > > > > Maybe a more interesting example could be something that touches > global > > vars, or does IO, ... ? > > Very good point! With what I'm doing, simply multiplying items by two, > you'd want the result to be an unevaluated, lazy sequence which is why > map would be preferred. > > But supposing I was doing something like you suggested where I really > do want to force the evaluation of all the items in the sequence, do > my rules of thumb make sense? > > > I haven't thought really hard about it, what it written seems correct > to me. > > But I think the first point is a little bit dangerous without a side > note : "if you already have the seq, then call 'doall or 'dorun on it". > Indeed, if you're dealing with a seq that is passed around, you may > end up calling dorun or doall on the seq in several places in the > code, which may lead to problems if you have side effects in them ! > So to prevent this risk : either the call to 'doall or 'dorun is > factorized, and it will certainly be factorized near the place where > the seq is generated (thus almost falling back to your second case > "you don't have generated the seq yet"), either you haven't side > effects at all, and you fall back to an idiomatic use of 'map or > another lazy-seq generating function, without the need to call 'doall > or 'dorun on them. > > HTH, > > -- > Laurent > > > > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
