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
-~----------~----~----~----~------~----~------~--~---

Reply via email to