do you mean that, when the string it outputted like: => (println k) (012340 1 2 3 4) nil => (prn k) "(012340 1 2 3 4)" nil
the side effects of evaluating k being mixed into the output could affect you (other than just visually in the repl) ? if ie. you redirect *out* to some file with the purpose of saving and later restoring that? Well, I don't actually like this myself (ever since I've encountered the map println example I've given) but I ignored it because people didn't seem to find it a big deal and nothing I could do about it + it only affected me in viewing REPL output. But I'm not sure if it is clear to you what is happening (perhaps I misunderstand what you're saying), it's only when showing the value of the string (k in this case) that the text shown is mixed, but the value of k is accurate, as seen below: On Sat, Feb 9, 2013 at 7:30 PM, Conrad <drc...@gmail.com> wrote: > I tested this in the latest 1.5.0-RC6: > > => (def k (pr-str (for [x (range 5)] > (do (pr x) > x)))) > #'user/k > => k > "(012340 1 2 3 4)" > => (= "[0 1 2 3 4]" k) true On Sat, Feb 9, 2013 at 8:03 PM, Conrad <drc...@gmail.com> wrote: > I agree when you print to stdout you'd expect lazily evaluated output to > be mangled in. > > However, it would seem more natural to me that if you print something to a > string it is counter intuitive for incidental writes to stdout to be > redirected to the string, as well- There is also nothing in the > documentation that suggests this would happen. > > Also, it would be technically relatively easy to change this. > > On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote: > >> here's a simpler example: >> => (map println '(1 2 3)) >> (1 >> 2 >> nil 3 >> nil nil) >> => (dorun (map println '(1 2 3))) >> 1 >> 2 >> 3 >> nil >> >> >> >> On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ <atk...@gmail.com> wrote: >> >>> actually replacing vec with dorun or doall, would've been a better >>> example :) >>> >>> >>> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ <atk...@gmail.com> wrote: >>> >>>> I think it's an illusion from being lazy ? >>>> => (def k (pr-str (vec (for [x (range 5)] >>>> ** (do (pr x) >>>> ** x))))) >>>> 01234 >>>> #'datest1.ret/k >>>> => k >>>> "[0 1 2 3 4]" >>>> >>>> >>>> >>>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad <drc...@gmail.com> wrote: >>>> >>>>> I tested this in the latest 1.5.0-RC6: >>>>> >>>>> => (def k (pr-str (for [x (range 5)] >>>>> (do (pr x) >>>>> x)))) >>>>> #'user/k >>>>> => k >>>>> "(012340 1 2 3 4)" >>>>> >>>>> This seems wrong to me... I can see what would be needed to fix it in >>>>> clojure/core.clj, but it would require creating several additional private >>>>> functions. Does anyone know if this behavior is intentional? >>>>> >>>>> -- >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@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+u...@**googlegroups.com >>>>> >>>>> For more options, visit this group at >>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to clojure+u...@**googlegroups.com. >>>>> >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Please correct me if I'm wrong or incomplete, >>>> even if you think I'll subconsciously hate it. >>>> >>>> >>> >>> >>> -- >>> Please correct me if I'm wrong or incomplete, >>> even if you think I'll subconsciously hate it. >>> >>> >> >> >> -- >> Please correct me if I'm wrong or incomplete, >> even if you think I'll subconsciously hate it. >> >> -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Please correct me if I'm wrong or incomplete, even if you think I'll subconsciously hate it. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
