Different error reporting wrt java.lang types a new feature of 1.3.0-alpha2?
Hi, I've just run across a different error reporting in 1.3.0-alpha2 to the one in 1.2. See the sample below. Clojure 1.3.0-alpha2 user=> (use 'clojure.contrib.monads) nil user=> ((fetch-val 1) 4) ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn clojure.contrib.monads/fetch-val/fn--793 (monads.clj:369) Clojure 1.2.0 user=> (use 'clojure.contrib.monads) nil user=> ((fetch-val 1) 4) java.lang.ClassCastException: java.lang.Integer cannot be cast to clojure.lang.IFn (NO_SOURCE_FILE:0) Is it intended? Why does the error message contain j.l.Integer in 1.2 whereas j.l.Long in 1.3.0-alpha2? It seems as a possible difference in memory usage (a wider type) or anything I couldn't think of atm, but rises a red flag in my mind. Shall I be concerned w/ it or is it not that important? Please explain for me being a clojure newcomer. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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
Re: Different error reporting wrt java.lang types a new feature of 1.3.0-alpha2?
I don't recall all the reasons and details from Rich's conj talk, but this is expected behavior now; your numbers are now Longs internally by default. See http://github.com/clojure/clojure/commit/845c63e9317826a5564ef766550562b3fbe68181 Chris On Thu, Oct 28, 2010 at 6:00 AM, Jacek Laskowski wrote: > Hi, > > I've just run across a different error reporting in 1.3.0-alpha2 to > the one in 1.2. See the sample below. > > Clojure 1.3.0-alpha2 > user=> (use 'clojure.contrib.monads) > nil > user=> ((fetch-val 1) 4) > ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn > clojure.contrib.monads/fetch-val/fn--793 (monads.clj:369) > > Clojure 1.2.0 > user=> (use 'clojure.contrib.monads) > nil > user=> ((fetch-val 1) 4) > java.lang.ClassCastException: java.lang.Integer cannot be cast to > clojure.lang.IFn (NO_SOURCE_FILE:0) > > Is it intended? Why does the error message contain j.l.Integer in 1.2 > whereas j.l.Long in 1.3.0-alpha2? It seems as a possible difference in > memory usage (a wider type) or anything I couldn't think of atm, but > rises a red flag in my mind. > > Shall I be concerned w/ it or is it not that important? Please explain > for me being a clojure newcomer. > > Jacek > > -- > Jacek Laskowski > Notatnik Projektanta Java EE - http://jaceklaskowski.pl > > -- > 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 -- 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
"OS process timed out" with clutch view server for Couch
Hi, did anyone encounter "OS process timed out" errors with the clutch view server for Couch? Defining the same view with javascript works fine, but when using clojure the view hangs and Couch basically logs "OS process timed out" errors. The command line seems to work. I could start the view server manually and chat with it to get the desired result. This happens on Windows, FWIW. Sincerely Meikel -- 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
Re: Different error reporting wrt java.lang types a new feature of 1.3.0-alpha2?
Here we go: http://david-mcneil.com/post/1393750407/clojure-conj-day-1-notes Check the notes at the bottom from Rich's talk; it's the part about unified primitives and boxed numbers. Chris On Thu, Oct 28, 2010 at 7:20 AM, Chris Maier wrote: > I don't recall all the reasons and details from Rich's conj talk, but > this is expected behavior now; your numbers are now Longs internally > by default. > > See > http://github.com/clojure/clojure/commit/845c63e9317826a5564ef766550562b3fbe68181 > > Chris > > On Thu, Oct 28, 2010 at 6:00 AM, Jacek Laskowski > wrote: >> Hi, >> >> I've just run across a different error reporting in 1.3.0-alpha2 to >> the one in 1.2. See the sample below. >> >> Clojure 1.3.0-alpha2 >> user=> (use 'clojure.contrib.monads) >> nil >> user=> ((fetch-val 1) 4) >> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn >> clojure.contrib.monads/fetch-val/fn--793 (monads.clj:369) >> >> Clojure 1.2.0 >> user=> (use 'clojure.contrib.monads) >> nil >> user=> ((fetch-val 1) 4) >> java.lang.ClassCastException: java.lang.Integer cannot be cast to >> clojure.lang.IFn (NO_SOURCE_FILE:0) >> >> Is it intended? Why does the error message contain j.l.Integer in 1.2 >> whereas j.l.Long in 1.3.0-alpha2? It seems as a possible difference in >> memory usage (a wider type) or anything I couldn't think of atm, but >> rises a red flag in my mind. >> >> Shall I be concerned w/ it or is it not that important? Please explain >> for me being a clojure newcomer. >> >> Jacek >> >> -- >> Jacek Laskowski >> Notatnik Projektanta Java EE - http://jaceklaskowski.pl >> >> -- >> 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 > -- 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
Re: Fastest way to generate comma-separated list
> Does this help? > > user> (use 'clojure.string) > nil > user> (join "," (range 10)) > "0,1,2,3,4,5,6,7,8,9" It still doesn't work for the list of strings. But thanks for reminding about it. -- 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
Re: Fastest way to generate comma-separated list
> Are you looking for pr-str? > > user> (pr-str "foo") > "\"foo\"" Yeah, that's exactly what I tried to implement with my `pr-to-str`, thank you. -- 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
Re: Let usage question
On Wed, Oct 20, 2010 at 3:21 PM, Rich Hickey wrote: > > > On Oct 20, 1:34 pm, cej38 wrote: >> This question leads into something that I read in Joy of Clojure (page >> 161 in the latest MEAP edition): >> "If you manage to hold onto the head of a sequence somewhere within a >> function, then that sequence will be prevented from being garbage >> collected. The simplest way to retain the head of sequence is to bind >> it to a local. This condition can occur with any type of value bind be >> it to a reference type or through the usage of let or binding." >> >> I am not sure what this means, but I think it would mean that using >> let as you do, could cause garbage collection problems. Thus, it >> might be better to follow the advice of Stuart and Luc. >> >> Chad >> >> PS. Clarification of the statement from the Joy of Clojure would be >> helpful. >> > > That advice seems stale, given: > > http://groups.google.com/group/clojure/msg/9b4e268b85c20cd6 > > let-bound locals get cleared on last use. The quoted section should perhaps be clarified with better wording, but the example immediately following that quote still accurately demonstrates the point we were trying to make: (let [r (range 1e9)] [(first r) (last r)]) ;=> [0 9] (let [r (range 1e9)] [(last r) (first r)]) ; java.lang.OutOfMemoryError: GC overhead limit exceeded "Clojure's compiler can deduce that in the first example the retention of `r` is no longer needed when the computation of `(last r)` occurs and therefore aggressively clear it. However, in the second example the head is needed later in the overall computation and can no longer be safely cleared." This is dramatically better than the "invisible" head-holding that sometimes happened in earlier versions of Clojure (and was noted in earlier versions of JoC), but is still good to be aware of. --Chouser http://joyofclojure.com/ -- 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
reducing terms in vector
Hi! A little stuck on how to do this efficiently. I have data that looks like this ( [ [1 2] [3 4] [5 6] ... ] [ [5 6] [7 8] [9 0] ... ] ...) I am trying to sum the vector pairs, e.g [6 8] [10 12] [14 6] thx! -- 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
Re: reducing terms in vector
> A little stuck on how to do this efficiently. I have data that looks > like this > > ( [ [1 2] [3 4] [5 6] ... ] [ [5 6] [7 8] [9 0] ... ] ...) > > I am trying to sum the vector pairs, e.g > > [6 8] [10 12] [14 6] Try: user> (def all-pairs '([ [1 2] [3 4] [5 6] ] [[5 6] [7 8] [9 0]]) ) #'user/all-pairs user> (defn sum-vec [& pts] (apply vector (apply map + pts))) #'user/sum-vec user> (apply map sum-vec all-pairs) ([6 8] [10 12] [14 6]) user> U -- 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
Re: reducing terms in vector
I don't know if use of `partial' is considered idiomatic, but I think it's the clearest in cases like this. user> (def all-pairs '([ [1 2] [3 4] [5 6] ] [[5 6] [7 8] [9 0]]) ) #'user/all-pairs user> (apply map (partial map +) all-pairs) ((6 8) (10 12) (14 6)) -- Eric Ulises writes: >> A little stuck on how to do this efficiently. I have data that looks >> like this >> >> ( [ [1 2] [3 4] [5 6] ... ] [ [5 6] [7 8] [9 0] ... ] ...) >> >> I am trying to sum the vector pairs, e.g >> >> [6 8] [10 12] [14 6] > > Try: > > user> (def all-pairs '([ [1 2] [3 4] [5 6] ] [[5 6] [7 8] [9 0]]) ) > #'user/all-pairs > user> (defn sum-vec [& pts] > (apply vector (apply map + pts))) > #'user/sum-vec > user> (apply map sum-vec all-pairs) > ([6 8] [10 12] [14 6]) > user> > > U -- 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
Re: Installing Clojure CLR
What is the full path of that program in the 1.2.0 bundle? I can't seem to find it. On Oct 27, 4:23 pm, dmiller wrote: > Let me know on the error. > > Re REPL: run Clojure.Main.exe to start. > > -David > > On Oct 27, 2:54 pm, Sean Devlin wrote: > > > So, I just started running w/ Clojrue CLR. I'm trying to get 1.2 up > > and running. I followed the instructions here: > > >http://github.com/richhickey/clojure-clr/wiki/Getting-started-binary-... > > > And got an error report. Doesn't seem like a show stopper, but I can > > post it later. Are there instructions somewhere on how to start a > > REPL? > > > Sean -- 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
apply an higher order function on an arbitrary nested data structure
I would like to apply an higher order function on an arbitrarily nested data structure which yields exactly the same structure but the original values replaced by the result of applying the passed in function. This is somewhat akin to the fmap function in Functor type class in haskell. I had a brief discussion with Christophe Grande at the Conj and he mentioned I post it to the group. Thanks, Amitava Shee -- 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
encoding of non-ascii symbols in clojure.contrib.json
Hello all I switched from org.danlarkin/clojure-json library to clojure.contrib.json, and found that all non-ascii characters are encoded as \u characters. But information on json.org states that character could be "any-Unicode-character-except-"-or-\-or-control-character" So, it seems that this is a bug in clojure.contrib.json... And this lead to increased traffic when transferring text with non-ascii characters. Should I create a bug for this case (and provide patch)? -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/http://alexott.net/ http://alexott-ru.blogspot.com/ Skype: alex.ott -- 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
Re: apply an higher order function on an arbitrary nested data structure
Like my same fn or something different? Maybe combine it with prewalk? Sean On Oct 28, 10:42 am, Amitava Shee wrote: > I would like to apply an higher order function on an arbitrarily > nested data structure which yields exactly the same structure but the > original values replaced by the result of applying the passed in > function. > > This is somewhat akin to the fmap function in Functor type class in > haskell. I had a brief discussion with Christophe Grande at the Conj > and he mentioned I post it to the group. > > Thanks, > Amitava Shee -- 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
Re: apply an higher order function on an arbitrary nested data structure
Functor's fmap in Haskell is passed where to apply the function as an (hidden in the type class dictionary) argument. You would need somehow to be more specific about where you want to apply your function in the data-structure. (On predefined position, a la Functor, or on every leaf, with a definition of what a leaf is for you) -- 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
Re: apply an higher order function on an arbitrary nested data structure
Without each type specifying where it would like the function applied
the result will be sort of hacky, but here's my hackey attempt at fmap
in clojure.
It makes some assumptions (e.g. you would only want to apply f to the
values rather than the keys of a hash). Also I'm not sure what the best
way is to check is a symbol is a function in Clojure.
user> (defn fmap [f arg]
(cond
(or (fn? arg) (= (class arg) clojure.lang.MultiFn)) (comp f arg)
(list? arg) (map (partial fmap f) arg)
(vector? arg) (vector (map (partial fmap f) arg))
(map? arg) (apply hash-map (mapcat (fn [[k v]] [k (fmap f v)])
arg))
true (f arg)))
#'user/fmap
user> ((fmap (partial + 1) sqrt) 9)
4
user> (fmap (partial + 1) (list 1 {:a 2 :b 3} 4))
(2 {:a 3, :b 4} 5)
user>
--
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
Re: Images in autodoc?
In order to better inform my thinking here, I want to ask: "So what's the target here?" Are we looking to enhance Clojure's core documentation or do you have specific projects of your own for which you'd like these features? For example, my rationale for images is that I want to be able to include representative output graphs in the Incanter documentation. The reason I ask this is that I'm trying to distinguish between things we're proposing because we'd like to use them ourselves in areas we control and things we're proposing because we'd like to change the overall way documentation is done (both reasonable discussions, but different). One of the things I'm working on is making available a full dataset with all the Var doc in clojure format so you can pull sample doc strings (and other info if you want). This is important for testing autodoc extensions against the existing population of strings. Tom -- 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
Re: encoding of non-ascii symbols in clojure.contrib.json
It's not a bug, but a design decision based on the fact that encoding is so easy to screw up. I'd accept a patch that made it optional. -S On Thu, Oct 28, 2010 at 11:02 AM, Alex Ott wrote: > Hello all > > I switched from org.danlarkin/clojure-json library to > clojure.contrib.json, and found that all non-ascii characters are encoded > as \u characters. But information on json.org states that character > could be "any-Unicode-character-except-"-or-\-or-control-character" > > So, it seems that this is a bug in clojure.contrib.json... And this lead to > increased traffic when transferring text with non-ascii characters. Should > I create a bug for this case (and provide patch)? > > -- > With best wishes, Alex Ott, MBA > http://alexott.blogspot.com/ http://alexott.net/ > http://alexott-ru.blogspot.com/ > Skype: alex.ott > -- 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
Re: apply an higher order function on an arbitrary nested data structure
Okay, you're re-inventing clojure.walk. Please take a look at that
namespace.
On Oct 28, 11:52 am, "Eric Schulte" wrote:
> Without each type specifying where it would like the function applied
> the result will be sort of hacky, but here's my hackey attempt at fmap
> in clojure.
>
> It makes some assumptions (e.g. you would only want to apply f to the
> values rather than the keys of a hash). Also I'm not sure what the best
> way is to check is a symbol is a function in Clojure.
>
> user> (defn fmap [f arg]
> (cond
> (or (fn? arg) (= (class arg) clojure.lang.MultiFn)) (comp f arg)
> (list? arg) (map (partial fmap f) arg)
> (vector? arg) (vector (map (partial fmap f) arg))
> (map? arg) (apply hash-map (mapcat (fn [[k v]] [k (fmap f v)])
> arg))
> true (f arg)))
> #'user/fmap
> user> ((fmap (partial + 1) sqrt) 9)
> 4
> user> (fmap (partial + 1) (list 1 {:a 2 :b 3} 4))
> (2 {:a 3, :b 4} 5)
> user>
--
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
parrot vm
Is anyone working on clojure for the parrot vm? -Terrance -- 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
Re: Images in autodoc?
On Thu, Oct 28, 2010 at 12:19 PM, Tom Faulhaber wrote: > In order to better inform my thinking here, I want to ask: "So what's > the target here?" > > Are we looking to enhance Clojure's core documentation or do you have > specific projects of your own for which you'd like these features? All of the above, but before core documentation is changed, there should be proven value, which would come from other projects making use of the documentation extensions. > For example, my rationale for images is that I want to be able to > include representative output graphs in the Incanter documentation. > > The reason I ask this is that I'm trying to distinguish between things > we're proposing because we'd like to use them ourselves in areas we > control and things we're proposing because we'd like to change the > overall way documentation is done (both reasonable discussions, but > different). I'm in this for the overall betterment of documentation in the clojure eco-system on the whole, if people find value in it (which I imagine people would be ok with richer, non-gobbledegooked documentation, if that can actually even be done). > One of the things I'm working on is making available a full dataset > with all the Var doc in clojure format so you can pull sample doc > strings (and other info if you want). This is important for testing > autodoc extensions against the existing population of strings. Great! This will certainly be helpful in the future. > -- > 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 -- http://www.apgwoz.com -- 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
Re: Installing Clojure CLR
Github automatically provides a zip of any tagged commit, so you can download the source for the 1.2.0 release. That's the link with the little tag icon on it. That is a source distribution and you'd have to follow a long involved path to get that to run. I took the instructions for that off the wikii. I don't recommend this. The best options at the moment: (1) Binary distribution: (a) clojure-clr-1.2.0.zip (b) clojure-clr-1.3.0-alpha1-debug-3.5.zip (c) clojure-clr-1.3.0-alpha1-debug-4.0.zip (2) Source distribution: download the repo, use the master branch. The binary distributions are EXE/DLL/CLJ, no C# source, projects or solutions. To start the REPL, you'll find Clojure.Main.exe in the top- level directory. The 1.2.0 distribution is .NET 3.5 only. The 1.3.0-alpha1 distributions give a choice of runtime. The master branch at present is pretty much the same as 1.2 except for the new build process + conversion to VS2010 and two small bug fixes. The wiki has instructions for getting the source ready to compile in VS2010. Basically, download the repo, download a zip with support DLLs and unzip in the right place, and go. On Oct 28, 9:08 am, Sean Devlin wrote: > What is the full path of that program in the 1.2.0 bundle? I can't > seem to find it. > > On Oct 27, 4:23 pm, dmiller wrote: > > > Let me know on the error. > > > Re REPL: run Clojure.Main.exe to start. > > > -David > > > On Oct 27, 2:54 pm, Sean Devlin wrote: > > > > So, I just started running w/ Clojrue CLR. I'm trying to get 1.2 up > > > and running. I followed the instructions here: > > > >http://github.com/richhickey/clojure-clr/wiki/Getting-started-binary-... > > > > And got an error report. Doesn't seem like a show stopper, but I can > > > post it later. Are there instructions somewhere on how to start a > > > REPL? > > > > Sean -- 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
Re: apply an higher order function on an arbitrary nested data structure
On 28 Oct 2010, at 16:42, Amitava Shee wrote: I would like to apply an higher order function on an arbitrarily nested data structure which yields exactly the same structure but the original values replaced by the result of applying the passed in function. This is somewhat akin to the fmap function in Functor type class in haskell. I had a brief discussion with Christophe Grande at the Conj and he mentioned I post it to the group. Look at clojure.contrib.generic.functor/fmap. That's a multimethod with implementations for the standard Clojure data structures. You can easily add your own for additional data structures. Konrad. -- 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
Re: Images in autodoc?
My interest is general improvement of Clojure documentation. At the conj, I spoke with Zack Kim about helping to improve the state of the documentation. My goal was to contribute additional documentation for vars that are lacking, as well as clarifying some of the more confusing doc strings (actually as a result of our talk, Zack is adding some community features to ClojureDocs where we can all comment and discuss doc string and submit possible revisions). As I started looking over the docs, it occurred to me that it would be nice to be able to format the strings (code formatting, bold, italics, lists, links, etc.), as well as add images where appropriate (I thought it might be helpful to have some images for describing how zippers work, for example). I wouldn't mind having these features for my own projects, but I think that Clojure as a whole could benefit from these improvements; anything to make it easier for newcomers to get up to speed. Chris On Thu, Oct 28, 2010 at 1:09 PM, Andrew Gwozdziewycz wrote: > On Thu, Oct 28, 2010 at 12:19 PM, Tom Faulhaber > wrote: >> In order to better inform my thinking here, I want to ask: "So what's >> the target here?" >> >> Are we looking to enhance Clojure's core documentation or do you have >> specific projects of your own for which you'd like these features? > > All of the above, but before core documentation is changed, there > should be proven value, which would come from other projects making > use of the documentation extensions. > >> For example, my rationale for images is that I want to be able to >> include representative output graphs in the Incanter documentation. >> >> The reason I ask this is that I'm trying to distinguish between things >> we're proposing because we'd like to use them ourselves in areas we >> control and things we're proposing because we'd like to change the >> overall way documentation is done (both reasonable discussions, but >> different). > > I'm in this for the overall betterment of documentation in the clojure > eco-system on the whole, if people find value in it (which I imagine > people would be ok with richer, non-gobbledegooked documentation, if > that can actually even be done). > >> One of the things I'm working on is making available a full dataset >> with all the Var doc in clojure format so you can pull sample doc >> strings (and other info if you want). This is important for testing >> autodoc extensions against the existing population of strings. > > Great! This will certainly be helpful in the future. > >> -- >> 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 > > > > -- > http://www.apgwoz.com > > -- > 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 -- 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
(count (filter ...)) much slower in 1.3 Alpha 2?
I have some code that counts the elements in a list that map to true
in a lookup table, looking something like this:
(def lookup-table {1 true, 2 false})
(def elements (range 100))
(count (filter lookup-table elements))
On my machine, with server mode enabled, the count + filter got ~10
times slower when I updated from 1.3 Alpha 1 to 1.3 Alpha 2:
(Alpha 1)
user=> (time (count (filter lookup-table elements)))
"Elapsed time: 181.262702 msecs"
1
(Alpha 2)
user=> (time (count (filter lookup-table elements)))
"Elapsed time: 2017.744155 msecs"
1
Which is weird because looking up elements in the table did not become
any slower:
(Alpha 1)
user=> (time (doseq [x elements] (lookup-table x)))
"Elapsed time: 159.033341 msecs"
nil
(Alpha 2)
user=> (time (doseq [x elements] (lookup-table x)))
"Elapsed time: 159.965861 msecs"
nil
--
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
Re: Different error reporting wrt java.lang types a new feature of 1.3.0-alpha2?
On Thu, Oct 28, 2010 at 1:49 PM, Chris Maier wrote: > Here we go: > > http://david-mcneil.com/post/1393750407/clojure-conj-day-1-notes > > Check the notes at the bottom from Rich's talk; it's the part about > unified primitives and boxed numbers. Thanks. That helped. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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
to macro or not?
hi, not looking to stir up a pot, looking to learn from people's experience. i've heard that in CL land, one is told to avoid macros as long as possible. i've heard other folks in the Clojure world say that if you aren't using macros, then sorta why bother use a Lisp since you are missing out on one of the most powerful differentiators. then reading about Conj it sounds like some folks say stay away from macros if you can. any way of teasing out when macros are ok? :-) i mean, are they only ok for the internals of the Clojure system? thanks. -- 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
Re: apply an higher order function on an arbitrary nested data structure
Okay, functor is a good idea but a weak implementation. My complaint is that it only provides functor behavior for the map function. same is a higher order function that works on anything, and is based on protocols. Take a look at the test cases to understand what I'm talking about. http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/test/lib/sfd/same_test.clj You can find the source for same here: http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/src/lib/sfd/same.clj This should replace the contrib lib, because it provide more functionality. On Oct 28, 2:05 pm, Konrad Hinsen wrote: > On 28 Oct 2010, at 16:42, Amitava Shee wrote: > > > I would like to apply an higher order function on an arbitrarily > > nested data structure which yields exactly the same structure but the > > original values replaced by the result of applying the passed in > > function. > > > This is somewhat akin to the fmap function in Functor type class in > > haskell. I had a brief discussion with Christophe Grande at the Conj > > and he mentioned I post it to the group. > > Look at clojure.contrib.generic.functor/fmap. That's a multimethod > with implementations for the standard Clojure data structures. You can > easily add your own for additional data structures. > > Konrad. -- 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
Re: to macro or not?
On Oct 28, 2010, at 2:55 PM, Raoul Duke wrote: > not looking to stir up a pot, looking to learn from people's > experience. i've heard that in CL land, one is told to avoid macros as > long as possible. i've heard other folks in the Clojure world say that > if you aren't using macros, then sorta why bother use a Lisp since you > are missing out on one of the most powerful differentiators. then > reading about Conj it sounds like some folks say stay away from macros > if you can. > > any way of teasing out when macros are ok? :-) i mean, are they only > ok for the internals of the Clojure system? Use a macro iff you can't do what you want with a function. -- 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
Re: to macro or not?
On Thu, Oct 28, 2010 at 1:08 PM, Michael Gardner wrote: > Use a macro iff you can't do what you want with a function. sorta true, perhaps leading to the kernel question: how do you decide what it really is you want/need to do? cf. the use of macros then not use of macros in enlive. sincerely. -- 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
Re: to macro or not?
Hi,
Am 28.10.2010 um 21:55 schrieb Raoul Duke:
> i've heard other folks in the Clojure world say that
> if you aren't using macros, then sorta why bother use a Lisp since you
> are missing out on one of the most powerful differentiators.
These people ^^^ should listen carefully to those people vvv.
> i've heard that in CL land, one is told to avoid macros as
> long as possible. Reading about Conj it sounds like some
> folks say stay away from macros if you can.
> any way of teasing out when macros are ok? :-) i mean, are they only
> ok for the internals of the Clojure system?
No. They are perfectly ok for any type of project. It's just a matter of being
the right tool for the job. Of course it's ok to use them, but please in a
responsible manner. If you don't need a macro, don't use one. Similar to: if
you don't need a Ref, don't use one.
Rule of thumb: can you write it as a function, do it. (Add a macro just to
sugar away any ugliness). If you can't write it as a function, you obviously
need a macro. Then use one.
Examples:
(with-bindings* {#'foo 5} (fn [] (do stuff))) works well as a function:
(defn with-bindings*
[bindings thunk]
(push-thread-bindings bindings)
(try
(thunk)
(finally
(pop-thread-bindings
Just do away the ugliness:
(defmacro with-bindings
[bindings & body]
`(with-bindings* ~bindings (fn [] ~...@body)))
To eg. def things you need a macro. Here a function won't work.
Hope this helps.
Sincerely
Meikel
--
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
Re: to macro or not?
On Thu, 28 Oct 2010 12:55:55 -0700 Raoul Duke wrote: > hi, > > not looking to stir up a pot, looking to learn from people's > experience. i've heard that in CL land, one is told to avoid macros as > long as possible. i've heard other folks in the Clojure world say that > if you aren't using macros, then sorta why bother use a Lisp since you > are missing out on one of the most powerful differentiators. then > reading about Conj it sounds like some folks say stay away from macros > if you can. Actually, these aren't really contradictory views. Macros are a powerful feature, and tend to be noted as the thing that sets LISPs apart from other languages. When you need them, nothing else will do the job. But they have downsides. For instance, they aren't a function, so aren't suitable to use as arguments to higher-order functions (another big part of LISP). So if you can do the job with a function, use a function instead. > any way of teasing out when macros are ok? :-) i mean, are they only > ok for the internals of the Clojure system? Last time it came up, there were three basic reasons given: 1) You need to control how many times an argument is evaluated. Commonly, either not at all or once, but possibly more than once. 2) Moving what you can of the computation into the compilation phase. This is a performance hack, so you should be converting functions to macros here. 3) You need it to get the API syntax you want (most commonly, a DSL). 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
Re: Clojure issue tracking is now on JIRA
Worked great for meThanks Stuart for wrestling with the dragon. I've created and shared a couple of simple issue filters to get issue- browsers started. Search for them under managing filters section. cheers, -tom On Oct 27, 6:07 pm, Stuart Halloway wrote: > Thanks to Contegix tech support and some RTFM on my part, self sign-on is now > enabled for JIRA athttp://dev.clojure.org/jira/browse/CLJ. Have at it. > > Stu -- 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
fundata1 -- Karmic Social Capital Benchmark and Shootout
I am happy to announce fundata1 -- the largest-ever program per RAM allocation in Haskell, originally implemented in Clojure and then OCaml and Haskell for social network modeling. http://github.com/alexy/fundata1 It has now become the first large-scale social networking benchmark with a real dynamic social graph built from the actual Twitter gardenhose, with the data OK'd by Twitter and supplied along with the benchmark. I wrote three reference implementations, all on github as well. Clojure and OCaml are quite basic, while Haskell community had a chance to optimize its data structures and in fact fix a GC integer overflow while working on it. You're welcome to fork and improve all of these implementations, and supply others! There's a Google Group, http://groups.google.com/group/fundata/ to discuss the shootout. There's also a blog about it and other functional things at http://functional.tv/ Let the fun begin! -- Alexy Khrabrov firstname.lastnameATgmaildotcom -- 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
How to simplify cond statements
Hi,
I have a code similar to this:
(def pairs (list [1 :a] [2 :b] [3 :c]))
...
(loop [ps pairs, ret {}]
(cond (empty? ps) ret
(some-test (first (first ps))) (recur (rest ps) (add-to-
result ret (first (first ps
:true (recur (rest ps) (do-smth-else ret (first (first
ps))
You can see that string (first (first ps)), which actually gets first
element of a first vector in pairs, occur many times. I can't move it
before cond, since ps may be empty and evaluating of (first (first
ps)) will produce an error (ok, it won't, but in general case it may).
Is there another way to simplify code to not repeat one form several
times?
--
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
Re: to macro or not?
On Fri, Oct 29, 2010 at 1:58 AM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> > > 3) You need it to get the API syntax you want (most commonly, a DSL). > > This last point is what I consider the most powerful feature of any language. And thats what makes Lispy languages a class apart. Use a macro where ever a particular type of problem, or solution to it, can be expressed more clearly using a macro, and the type of problem reappears more than once. -- http://hi.im/santosh -- 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
Re: How to simplify cond statements
user=> (doc ffirst)
-
clojure.core/ffirst
([x])
Same as (first (first x))
nil
user=>
That could help a bit :
Luc P.
andrei wrote ..
> Hi,
>
> I have a code similar to this:
>
> (def pairs (list [1 :a] [2 :b] [3 :c]))
> ...
> (loop [ps pairs, ret {}]
> (cond (empty? ps) ret
> (some-test (first (first ps))) (recur (rest ps) (add-to-
> result ret (first (first ps
> :true (recur (rest ps) (do-smth-else ret (first (first
> ps))
>
> You can see that string (first (first ps)), which actually gets first
> element of a first vector in pairs, occur many times. I can't move it
> before cond, since ps may be empty and evaluating of (first (first
> ps)) will produce an error (ok, it won't, but in general case it may).
> Is there another way to simplify code to not repeat one form several
> times?
>
> --
> 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
--
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
Re: How to simplify cond statements
I'd hoist the empty out of the cond using an if:
(if (empty? ps)
ret
(let [fps (first (first ps))]
(cond
...)))
On Thu, Oct 28, 2010 at 8:49 PM, andrei wrote:
> Hi,
>
> I have a code similar to this:
>
> (def pairs (list [1 :a] [2 :b] [3 :c]))
> ...
> (loop [ps pairs, ret {}]
> (cond (empty? ps) ret
> (some-test (first (first ps))) (recur (rest ps) (add-to-
> result ret (first (first ps
> :true (recur (rest ps) (do-smth-else ret (first (first
> ps))
>
> You can see that string (first (first ps)), which actually gets first
> element of a first vector in pairs, occur many times. I can't move it
> before cond, since ps may be empty and evaluating of (first (first
> ps)) will produce an error (ok, it won't, but in general case it may).
> Is there another way to simplify code to not repeat one form several
> times?
>
> --
> 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
--
http://www.apgwoz.com
--
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
Re: to macro or not?
I'll try to extend Mike's answer by one more example. Consider `and` Lisp macro. It is not a function, because it must evaluate it's arguments lazily, and using macros is the only way to do it. But try to apply `and` to the list of values (I know, that it's a job for a function `every?`, but how will you implement this function itself?): (apply and (list true true false true)) ==> error You cannot do it, since and is not a function. So, you need to use wrapper around `and`: (reduce #(and %1 %2) (list true true false true)) ==> false And this is still not the perfect solution, since it is not lazy. So you can see both advantages and disadvantages of using macros. -- 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
Re: to macro or not?
On Fri, 29 Oct 2010 06:30:27 +0530 Santosh Rajan wrote: > On Fri, Oct 29, 2010 at 1:58 AM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> > > 3) You need it to get the API syntax you want (most commonly, a DSL). > This last point is what I consider the most powerful feature of any > language. And thats what makes Lispy languages a class apart. Use a macro > where ever a particular type of problem, or solution to it, can be expressed > more clearly using a macro, and the type of problem reappears more than > once. I disagree - but I'm a big fan of code that writes code (this would be the second case - moving computations into the compiler). Computers are a "multiplier", in that they multiply the number computations (for a loose definition of computation) that a single human can do by many orders of magnitude. Macros (or code that writes code) make writing code become the computation being multiplied. LISP macros are the most effective way I know of writing code that writes code. The alternatives involve multiple languages, or writing files that are then fed back to the language processor. 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
Re: to macro or not?
On Thu, 28 Oct 2010 18:12:39 -0700 (PDT) andrei wrote: > > I'll try to extend Mike's answer by one more example. Consider `and` > Lisp macro. It is not a function, because it must evaluate it's > arguments lazily, and using macros is the only way to do it. Actually, this is the first case, and a classic example of it: you need to control how many times the arguments are evaluated. > But try > to apply `and` to the list of values (I know, that it's a job for a > function `every?`, but how will you implement this function itself?): > > (apply and (list true true false true)) ==> error And this is the issue of not being able to pass macros to higher order functions. > You cannot do it, since and is not a function. So, you need to use > wrapper around `and`: > > (reduce #(and %1 %2) (list true true false true)) ==> false > > And this is still not the perfect solution, since it is not lazy. > > So you can see both advantages and disadvantages of using macros. Which is why you only want to use them when you have to. If you don't need the advantages, why put up with the disadvantages? 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
Re: How to simplify cond statements
Andrei,
You could just bind another local variable in the loop form:
(loop [ps pairs
ret {}
ffps (ffirst ps)]
(cond (empty? ps) ret
(some-test ffps) (recur (rest ps) (add-to-result ret ffps) (ffirst
(rest ps)))
:true (recur (rest ps) (do-sth-else ret ffps) (ffirst (rest ps )
I think I like Andrew's solution better though.
But you probably want to use 'reduce' instead of 'loop' anyway:
(reduce (fn [ret [key val]] (if (some-test key) (add-to-result ret key)
(do-sth-else ret key))) {} pairs)
Notice how you can destructure each pair in a convenient way.
BTW, do you really mean to call 'add-to-result' and 'do-sth-else' with a map
and a key but no value?
Have all good days,
David Sletten
On Oct 28, 2010, at 8:49 PM, andrei wrote:
> Hi,
>
> I have a code similar to this:
>
> (def pairs (list [1 :a] [2 :b] [3 :c]))
> ...
> (loop [ps pairs, ret {}]
>(cond (empty? ps) ret
> (some-test (first (first ps))) (recur (rest ps) (add-to-
> result ret (first (first ps
> :true (recur (rest ps) (do-smth-else ret (first (first
> ps))
>
> You can see that string (first (first ps)), which actually gets first
> element of a first vector in pairs, occur many times. I can't move it
> before cond, since ps may be empty and evaluating of (first (first
> ps)) will produce an error (ok, it won't, but in general case it may).
> Is there another way to simplify code to not repeat one form several
> times?
>
> --
> 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
--
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
Re: apply an higher order function on an arbitrary nested data structure
On 28.10.2010, at 21:57, Sean Devlin wrote: > Okay, functor is a good idea but a weak implementation. My complaint > is that it only provides functor behavior for the map function. same > is a higher order function that works on anything, and is based on > protocols. Take a look at the test cases to understand what I'm > talking about. I agree that a muiltimethod is no longer the best choice for implementing functor-like functionality in Clojure, now that we have protocols. But I think that the mathematical abstraction of a functor is of use (for reasoning about programs) and should be visible as such. "same" seems more concerned about abstracting away implementation details, e.g. between the different map implementations, than with implementing a well-defined mathematical concept. > This should replace the contrib lib, because it provide more > functionality. I'd say that something like same should be used to implement something like fmap. Konrad. -- 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
Test for whether a function accepts a particular arity.
(defn accepts-arity? [n f] (reduce #(or %1 (= n (count %2)) (and (= '& (last (butlast %2))) (>= n (- (count %2) 2 false (:arglists (meta f This works only if f has metadata -- anonymous lambdas don't but functions defined using defn do. I thought this up while reading some intro to clojure.contrib.monad that mentioned that m-lift needs to be given an arity; it seems to me m-lift could probably be implemented to use the arities in the function metadata, when available, to make this optional. -- 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
