Hi, I'am not really sure on your explanation here.
For me if the processor, JVM or clojure compiler cannot prove it doesn't change the semantics, the optimization will not be applyed. readLine behing a java method call, it can perform any operations and thus clojure compiler will not change the execution order (or number of calls to it). I agree that some clojure functions explicitely expect that no side effect will be performed to perform futher optimizations, but then it is stated in the documentation. On Nov 1, 11:33 am, Ingo <ingo.wechs...@googlemail.com> wrote: > The problem with the direct call of the readLine() method is that it might > not work some day like it appears to work today. Specifically, the meaning > of your program depends on: > > - evaluation order the compiler chooses > - the fact that the compiler obviously does not do common subexpression > elimination in this case, maybe because it sees that readLine() is not > pure, but who knows. -- 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
