On Mon, 6 Dec 2010 16:50:40 -0800 (PST) javajosh <javaj...@gmail.com> wrote:
> 1. What is the justification for using a map as a function? I find > this to be very confusing. The same as using a keyword for a function - it lets you write shorter code. > 2. In practice, I find myself wincing when needing to decide whether > or not to type an open-paren. Is that a common thing? I don't believe so. Hopefully it will go away soon. > 3. Is there a compendium of recursive idioms, ideally expressed in > clojure? Including indentation conventions! (Is there an opportunity > for a python inspired pre-processor that interprets indentation as > parens?) Well, I've always liked D.W. Barron's "Recursive Techniques in Programming", and found Eric S. Robert's "Thinking Recursively" to be worth reading, but neither are in LISP. On the other hand, I'm not sure that a LISP programmer would see the value in a compendium of recursive idioms. > 4. Why don't long-running clojure programs monotonically increase in > heap usage if all data-structures are immutable? For the same reason that Java programs don't monotonically increase in heap usage: the Java garbage collector recycles storage that's no longer in use. > 5. In the REPL, isn't it redundant to always have to type the top- > level parens? Not really. If you don't do that, the REPL has to figure out what a naked token on the command line is, and then decide whether or not to add the parens to it. That said, what you're asking about has been used in various LISP systems dating back to the last century, and is known as an evalquote REPL (as opposed to the more common eval REPL used by Clojure). There are a number of CL implementations floating around the web, but I haven't seen one for clojure. > 6. Is there a place to get guidlines on macro idioms? The feature is > so powerful that it seems like it would be easy to misuse it and crack > a programmers head like a nut with a badly structured macro. Halloway's "Programming Clojure" has a good chapter on macros, but it's not as comprehensive as a good CL book's coverage (ask if you want references, but I wouldn't recommend learning CL just to help with clojure). In particular, he doesn't talk about using macros as an optimization technique. It does give a good set of rules for writing macros: 1) Don't write macros. 2) Only write macros if that's the only way to encapsulate a pattern. 3) You can write a macro if it makes life easier for your callers than the equivalent function (my aside: write the function, then have the macro invoke it). > I also have some philosophical questions: Given that I have to live in the poor physical approximation to the real world described by mathematics, I'm going to skip most of these. > 1. Isn't the world actually imperative? And mutable? Collaboration > *is* a messy proposition in real life. It's hard to fix your car, and > even harder to have lots of people fix your car. I find the "it models > the real world better" justification for functional programming rather > confusing. (Indeed, the CPU and physical memory also have an > imperative relationship!) > 2. 'Side-effects' are treated almost as a bad word by most functional > programming advocates. And yet, aren't ALL programs executed for their > side-effects? Does "side effect" perhaps then require a qualification > or a tighter definition? Or perhaps side-effects "aren't that bad"? > 3. What is the relationship between the "shape" of a clojure program > and the runtime call stack? (I ask because a clojure program looks > strikingly similar to the callstack of an ordinary program when you > 'pause' a thread.) > 4. Is it possible (and/or advisable) to introduce a typing system on > top of clojure? E.g. a macro-form along the lines of (fnif > type_function function args) <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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
