interleave with one argument
Hi, I just solved the Replicate a Sequence problem on 4clojure [1] using interleave. However, I noticed that interleave cannot be called with a single argument. My first attempt at solving the problem was like this: (defn replicate-n-times [xs n] (apply interleave (replicate n xs))) This works fine for n 1: clojure= (replicate-n-times [1 2 3] 3) (1 1 1 2 2 2 3 3 3) However, for n = 1 the function fails with an exception: clojure= (replicate-n-times [1 2 3] 1) ArityException Wrong number of args (1) passed to: core$interleave clojure.lang.AFn.throwArity (AFn.java:437) I had to add a special case to make this work: (fn replicate-n-times [xs n] (if (= n 1) xs (apply interleave (replicate n xs I think it would be nice if interleave called with a single argument would just return the argument itself, just like single-argument + and * do. Regards, Denis Washington [1] http://www.4clojure.com/problem/33 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Sample application as showcase of Clojure DSL / Metaprogramming?
Am 24.09.2011 23:17, schrieb alexey.petrushin: Hello, I'm learning Clojure (work mainly with Java and Ruby), interested in it after reading Paul Graham and watched very interesting presentation about persistent data structures by Rich Hickey. Speaking of Paul Graham, have you read On Lisp? It's code samples are based on pre-ANSI Common Lisp, but are very impressive and show nicely what Lisp macros can do. The book is available for download on Graham's homepage: http://www.paulgraham.com/onlisp.html Regards, Denis -- 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
Why visible in-transaction changes?
Hi, I really like the idea of grouping mutation in my programs into transactions in order to reduce the number of possible states make make reasoning about them easier (in the spirit of the mutable state discussion of [1]) and thought that Clojure's dosync + refs might be the ideal way to do this. However, I was disappointed to find out the following: (def r (ref 1)) (dosync (alter r #(+ 1 %)) (println @r)) (println @r) Output: 2 2 I would have hoped that changes to refs during an transaction wouldn't affect the in-transaction value of the ref (that is, I would have liked the code to print 1, then 2). This way, the view of the program's state would always be guaranteed to be consistent, even during a transaction, and there would be no fear of non-consistent in- transaction states breaking anything. The way it is currently work in Clojure, though, still requires one to take all such inconsistent states into account, rendering them effectively useless for the kind of state management I imagined. (Note that I am not talking about multi-threading here; my objective is to reduce the number of possible states in the single-threaded case, and make sure that every computation is based upon a consistent state.) Why was this behavior chosen, instead of only making changes to refs invisible until commited (even to the transaction commiting them)? I believe that the latter approach would actually fit better to Clojure in general. Maybe there could at least be an alternative dosync form that acts like this? Regards, Denis -- 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: Why visible in-transaction changes?
Am 23.09.2011 17:25, schrieb Stuart Halloway: I would have hoped that changes to refs during an transaction wouldn't affect the in-transaction value of the ref (that is, I would have liked the code to print 1, then 2). This way, the view of the program's state would always be guaranteed to be consistent, even during a transaction, and there would be no fear of non-consistent in- transaction states breaking anything. The way it is currently work in Clojure, though, still requires one to take all such inconsistent states into account, rendering them effectively useless for the kind of state management I imagined. (Note that I am not talking about multi-threading here; my objective is to reduce the number of possible states in the single-threaded case, and make sure that every computation is based upon a consistent state.) Why was this behavior chosen, instead of only making changes to refs invisible until commited (even to the transaction commiting them)? I believe that the latter approach would actually fit better to Clojure in general. Maybe there could at least be an alternative dosync form that acts like this? Regards, Denis There are a lot of scenarios that would become difficult or impossible with the semantics you propose. Do you have an example? On the other hand, what you want is quite simple to achieve: If you want consistent view of the the values of refs, deref them all at the start of the transaction. Fair enough, but if a transaction is split among several functions, this becomes difficult. Regards, Denis -- 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
