> HOFs and > lazy seqs add a bit more expense. Try deliberately throwing an > exception in lazy-seq and then (first (map this (map that ... > (my-exception-throwing-lazy-seq)))) and see how deep the stack trace > nests; the method call overheads do add up when there's many of them!
Tell me about it... these stacktraces are my daily bread. Once we had a misterious StackOverflowError in the middle of our non-recursive code. The culprit turned out to be concat, iteratively applied to an open-ended amount of vectors. > > But generally, it is even better when your clean-looking code performs > > well -- and if the compiler can achieve that, it obsoletes any > > specialized idioms for optimal code. > > No argument there. When a new version of Clojure comes out, I routinely invest enough time to read the new API docs cover-to-cover, searching for new interesting stuff. The problem is, some important changes don't happen through new API, but through subtle improvements in the behavior of existing API. For example, as of 1.2 we have something Rich named "fine-grained locals clearing" -- a killer feature for lazy seqs, but not mentioned anywhere in the docs and not easily googlable, unless you already heard the phrase. The feature you mention -- functions that accept primitive arguments -- seems to fall in this class. I continually worry that my code might be jumping through nonexistent hoops that I only imagine due to my incomplete understanding of Clojure. I think it is important to clearly document all such features, even more so than the API, where the source code is the ultimate, easily reachable documentation. -- 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
