Re: more vimclojure
I'd like to add how great I think VimClojure is. It's truly an amazing environment and I don't think I'd be able to enjoy clojure as much without it. I'm too committed to vim to learn emacs for a new language. Thanks a lot Meikel! On Apr 29, 10:13 am, Meikel Brandmeyer m...@kotka.de wrote: Hi Adrian, Am 29.04.2009 um 07:00 schrieb Adrian Cuthbertson: In the absence of an issue tracker at this time, could I mention the following relating to indenting; (defn xxx Some stuff... (defmacro xxx Some stuff... (defroutes xxx Some stuf... This can be configured using the lispwords option of Vim. Do a :setlocal lispwords+=defroutes and you should get the desired behaviour. This is a built-in functionality. Since I come from Scheme, I knew this option. However this question arose several times now, so I guess that people coming eg. from Java don't know this Vim option. So my cultural assumption that Lisp hackers know this is maybe true, but not really applicable here. I will extend the documentation. Thanks Meikel, great work! Thanks for the feedback! :) Sincerely Meikel smime.p7s 5KViewDownload --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: update-in wildcards?
(use '[clojure.contrib.generic.functor :only (fmap)])
(defn update-in-wildcard
Like update-in, but with :* as a wildcard matcher
([m [k ks] f args]
(condp = [(= k :*) (boolean ks)]
[true true] (fmap #(apply update-in-wildcard % ks f args) m)
[true false] (fmap f m)
[false true] (assoc m k (apply update-in-wildcard (get m k) ks f
args))
[false false] (assoc m k (apply f (get m k) args)
This seems to do what you want. I had a similar situation but hadn't
thought of abstracting it out in this way until I read your post. The
condp is somewhat ugly, but I didn't want nested if's checking for the
same condition. If anyone can think of a nicer way of doing the
conditional, let me know.
On Apr 10, 11:32 am, Ozzi Lee ozzi...@gmail.com wrote:
I have a structure of nested Maps and Vectors as follows:
(def document
{:sections
[{:items
[{:quantity 1}
{:quantity 2}]}
{:items
[{:quantity 3}
{:quantity 4}]}]})
The document has a vector of sections (one, in this case), each
section has a vector of items (two, here).
I want to increment the quantity of every item in every section. The
cleanest solution I've found this far is as follows:
(defn update-item [item]
(update-in item [:quantity] inc))
(defn update-section [section]
(update-in section [:items] (partial map update-item)))
(update-in document [:sections]
(partial map update-section))
I'm not concerned about map turning vectors into seqs.
If update-in supported some kind of wildcard, I could write this:
(update-in document [:sections * :items * :quantity] inc)
Where * is a wildcard, meaning any key.
Does the wildcard idea have any merit? Is there a better way to go
about this?
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
Re: making code readable
What about some sort of lint program? I'm thinking about something like pylint for clojure with configurable rules, but which will default to the standards agreed upon bu the clojure community. Even if you don't follow the rules 100%, it could be useful to see where you are deviating to be sure you really mean to in that situation. Plus it'd be a good coding exercise. -Mitch On Dec 30, 12:50 am, Mark H. mark.hoem...@gmail.com wrote: On Dec 29, 1:15 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote: It's early enough in the life of Clojure that we haven't developed any deeply held habits yet. I think it would be a good idea for you and other Clojure committers to at least suggest the way you think things should be done in code. If you think surrounding names of constants with plus signs is a good way to identify them as such, I'll gladly start doing that for the sake of consistency. I don't think it's a good idea for all of us to simply do what feels good because that will make it harder to read code written by others. Indeed, standards are good, but I do think part of the Lisp way (for good or ill) is to treat such standards less like dogma and more like gentle admonitions. There does seem to be a little of a culture clash latent in this discussion, between those with the Lisp ethos and those with the Java ethos. It has very little to do with naming conventions for variables, and very much to do with the level of playfulness and academic interest one has when approaching a new programming language: do I ask, ooo, how many lines of code do I need in order to express this infinite data structure? or how do I get my Web 2.0 application up and running with the least effort?. Both of these are good questions to ask: every serious computer science task needs both application to motivate theory, and theory to improve existing applications and inspire new ones. It's fun to see a language like Clojure motivate both groups of people and get them talking -- Rich has done great work in that respect by taking suggestions from both groups and creating the space for them to interact. It might be fun to make a list of books that folks on one side could read to get the sense of how the other side thinks. mfh --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
