On Tue, Jul 7, 2009 at 8:08 AM, Roman Roelofsen<[email protected]> wrote: > > (0 until 100) map (_ * 2) filter (_ % 3 == 0) > > I can easily read this line from left to right (just like english) and > instantly see whats going on. By contrast, I have to read the clojure > version a couple of times to understand it: > > (filter #(= 0 (rem % 3)) (map #(* 2 %) (range 100))) > > Is this just a matter of pratice? Do you find it easy to read the > clojure version?
Practice, yes. It often helps if you try to not get too much detail out of the initial left-to-right read, but instead just a sense of what's going on. Something like "filter something from a map over a range". Now you know where you're headed, and can read inside-out (or right-to-left) for the details. FWIW, I think it takes less knowledge to read most Clojure snippets. As with most syntaxy languages, that Scala example requires knowledge of precedence rules, grouping rules, etc. > Also, would it make sense to have a function like this: > > (apply-chain (range 100) (map #(* 2 %)) (filter #(= 0 (rem % 3)))) Perhaps. The idea has certainly been kicked around some. http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/2e206c645c2c34e2 > * Parametrization of "function groups" * (snip) > > Currently I can think of 2 approaches to implement this in clojure: > > a) Each function also defines a database parameter > The downside is that the caller needs to fill in the value every time. > > b) The function invocation needs be part of something else, e.g. (do- > with-db "mydbname" (db-write) (db-read) ... ). > Here, the caller still needs to be aware of this setting. (a) is most like OO, and a perfectly valid option. Instead of mydb.read(x) the user would call (db-read mydb x) -- same args, just bit different order. (b) is also reasonable, and not an option in most OO languages. This allows you to mention mydb once for a whole group of calls to db-* functions. The same functions could even allow both -- (db-read x) with one arg would use *the-db* and (db-read mydb x) with two args would use mydb. > * Real-world macros * > > Correct me if I am wrong, but it seems that people often use macros > for lazy evaluation of parameters. In Scala, it is quite easy to > accomplish the same via by-name parameters. E.g. > > def maybe(lazyarg: => Unit) = if (...) lazyarg > > lazyarg will be evaluated in the if clause, not when the method > 'maybe' gets invoked. I know that macros in clojure are much more > powerful. But what are selling points in pratice? What is a unique > feature of clojure's macro that you don't want to miss? Lazy args are an approachable example, but probably not my main usage of macros. If that's all you want, 'delay' might be a better option. I use macros anytime I have patterns in my code that I want to factor out but for which functions are insufficient. I know that's a bit vague, but I'm not sure how else to generalize it. Another common use case is to move certain kinds of lookups or computation from runtime to compile time. --Chouser --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
