Re: dotimes suggestion

2009-02-24 Thread Rich Hickey
On Feb 24, 5:36 am, Timothy Pratley wrote: > Disclaimer: I don't think this is an important issue. I'd like to hear > some wider opinions on this out of interest. > > So far I haven't found the nays compelling, but then its not really an > exciting feature either. I tend to come across (dotimes

Re: dotimes suggestion

2009-02-24 Thread Timothy Pratley
Disclaimer: I don't think this is an important issue. I'd like to hear some wider opinions on this out of interest. So far I haven't found the nays compelling, but then its not really an exciting feature either. I tend to come across (dotimes) where I want to get a rough feel for the timings on

Re: dotimes suggestion

2009-02-22 Thread Mirko
On Feb 22, 6:19 pm, Raffael Cavallaro wrote: > On Feb 22, 2:54 pm, Mirko wrote: > > > > > In lisp you would define it as (untested): > > > (defmacro print-times (reps text) > > `(do-times (i ,reps) > > (print ,text)) > > > (Not trying to force-feed lisp, just that I do not know the closure > >

Re: dotimes suggestion

2009-02-22 Thread Raffael Cavallaro
On Feb 22, 2:54 pm, Mirko wrote: > > In lisp you would define it as (untested): > > (defmacro print-times (reps text) > `(do-times (i ,reps) > (print ,text)) > > (Not trying to force-feed lisp, just that I do not know the closure > syntax). user=> (defmacro repeat-times [n & body]

Re: dotimes suggestion

2009-02-22 Thread Mirko
On Feb 22, 3:14 pm, Mark Volkmann wrote: > On Sun, Feb 22, 2009 at 1:54 PM, Mirko wrote: > > In my practice, almost every project (no matter how short it is) > > starts by writing raw code, and then, when I see what is being done > > often, replacing parts with macros that simplify the code an

Re: dotimes suggestion

2009-02-22 Thread Mark Volkmann
On Sun, Feb 22, 2009 at 1:54 PM, Mirko wrote: > In my practice, almost every project (no matter how short it is) > starts by writing raw code, and then, when I see what is being done > often, replacing parts with macros that simplify the code and make it > easier to read. But wouldn't it be nic

Re: dotimes suggestion

2009-02-22 Thread Mark Volkmann
On Sun, Feb 22, 2009 at 1:46 PM, David Nolen wrote: > I agree that this is initially confusion, but I think that if you spend more > than a couple of days with Clojure you will understand the ubiquitous and > liberal use of binding forms. I know I'm beating this to death and need to let this dro

Re: dotimes suggestion

2009-02-22 Thread Mirko
On Feb 21, 9:53 pm, André Thieme wrote: > On 21 Feb., 18:24, Mark Volkmann wrote: > > > Currently the dotimes macro requires its first argument to be a vector > > for binding a variable to the number of times the body should be > > executed. Inside the body, that variable is bound to the value

Re: dotimes suggestion

2009-02-22 Thread David Nolen
I agree that this is initially confusion, but I think that if you spend more than a couple of days with Clojure you will understand the ubiquitous and liberal use of binding forms. On Sun, Feb 22, 2009 at 2:42 PM, Mark Volkmann wrote: > > On Sun, Feb 22, 2009 at 1:34 PM, David Nolen > wrote: > >

Re: dotimes suggestion

2009-02-22 Thread Mark Volkmann
On Sun, Feb 22, 2009 at 1:34 PM, David Nolen wrote: > In general, I find that multiple arguments types for a function confusing. > If dotimes is going to take multiple types it should be a multifn. That > seems to imply a performance hit. > I think Clojure wisely does not (or rarely does not?) al

Re: dotimes suggestion

2009-02-22 Thread David Nolen
In general, I find that multiple arguments types for a function confusing. If dotimes is going to take multiple types it should be a multifn. That seems to imply a performance hit. I think Clojure wisely does not (or rarely does not?) allow for multiple types to be passed into a function. On top o

Re: dotimes suggestion

2009-02-21 Thread Mark Volkmann
On Sat, Feb 21, 2009 at 8:53 PM, André Thieme wrote: > > On 21 Feb., 18:24, Mark Volkmann wrote: >> Currently the dotimes macro requires its first argument to be a vector >> for binding a variable to the number of times the body should be >> executed. Inside the body, that variable is bound to t

Re: dotimes suggestion

2009-02-21 Thread André Thieme
On 21 Feb., 18:24, Mark Volkmann wrote: > Currently the dotimes macro requires its first argument to be a vector > for binding a variable to the number of times the body should be > executed. Inside the body, that variable is bound to the values from 0 > to that number minus 1. How about changing

Re: dotimes suggestion

2009-02-21 Thread Mark Volkmann
On Sat, Feb 21, 2009 at 5:01 PM, David Nolen wrote: > (defmacro again [n & body] > `(dotimes [~'_ ~n] ~...@body)) > (again 3 (println "Ho")) > On Sat, Feb 21, 2009 at 5:51 PM, samppi wrote: >> >> For now, I do: >> (dotimes [_ 3] (print "Ho")) >> >> But I also think it would be a nice, natural

Re: dotimes suggestion

2009-02-21 Thread David Nolen
(defmacro again [n & body] `(dotimes [~'_ ~n] ~...@body)) (again 3 (println "Ho")) On Sat, Feb 21, 2009 at 5:51 PM, samppi wrote: > > For now, I do: > (dotimes [_ 3] (print "Ho")) > > But I also think it would be a nice, natural addition. > > On Feb 21, 3:07 pm, Timothy Pratley wrote: > > +1

Re: dotimes suggestion

2009-02-21 Thread samppi
For now, I do: (dotimes [_ 3] (print "Ho")) But I also think it would be a nice, natural addition. On Feb 21, 3:07 pm, Timothy Pratley wrote: > +1 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To

Re: dotimes suggestion

2009-02-21 Thread Timothy Pratley
+1 --~--~-~--~~~---~--~~ 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 Fo

dotimes suggestion

2009-02-21 Thread Mark Volkmann
Currently the dotimes macro requires its first argument to be a vector for binding a variable to the number of times the body should be executed. Inside the body, that variable is bound to the values from 0 to that number minus 1. How about changing this macro to also accept an integer as the firs