Re: dotimes suggestion
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 some function: (time (dotimes [i 1] (stuff)) I'd benefit more from (time) having an arity 2 version taking the number of executions desired :P Again that's not exactly an earth-shattering feature either. Are there any real use cases for dotimes? It could almost be removed in favour of (for) only, it is only slightly more verbose. So far the objections raised against extending dotimes have been: 1) Complexity: having (dotimes 3 (stuff)) and (dotimes [i 3] (stuff i)) vs always using a binding even when not needed: (dotimes [_ 3] (stuff)) That's the question in a nutshell really... is it simpler or more complex? Having the option doesn't appear to hurt. (It is not a burden to learn or understand, and is not a breaking change). 2) Polymorphic arguments are bad: In general I agree it is wise to be wary, however it wouldn't be a unique situation: (find-doc re-string-or-pattern) (float-array size-or-seq) (seque n-or-q s) Numbers and bindings are completely distinguishable in this case. There would be no runtime hit as the trivial check would be macro time anyhow. 3) You can write your own like xyz: Seems irrelevant given Mark has indeed written his own. Regards, Tim --~--~-~--~~~---~--~~ 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: dotimes suggestion
On Feb 24, 5:36 am, Timothy Pratley timothyprat...@gmail.com 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) where I want to get a rough feel for the timings on some function: (time (dotimes [i 1] (stuff)) I'd benefit more from (time) having an arity 2 version taking the number of executions desired :P Again that's not exactly an earth-shattering feature either. Are there any real use cases for dotimes? It could almost be removed in favour of (for) only, it is only slightly more verbose. So far the objections raised against extending dotimes have been: 1) Complexity: having (dotimes 3 (stuff)) and (dotimes [i 3] (stuff i)) vs always using a binding even when not needed: (dotimes [_ 3] (stuff)) That's the question in a nutshell really... is it simpler or more complex? Having the option doesn't appear to hurt. (It is not a burden to learn or understand, and is not a breaking change). 2) Polymorphic arguments are bad: In general I agree it is wise to be wary, however it wouldn't be a unique situation: (find-doc re-string-or-pattern) (float-array size-or-seq) (seque n-or-q s) Numbers and bindings are completely distinguishable in this case. There would be no runtime hit as the trivial check would be macro time anyhow. 3) You can write your own like xyz: Seems irrelevant given Mark has indeed written his own. I'm not opposed to supporting (dotimes 42 (foo)) given the objections raised thus far. Rich --~--~-~--~~~---~--~~ 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: dotimes suggestion
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 of that it's trivial to produce a macro on top of dotimes that does what you want that doesn't spend time checking the type of it's argument. On Sat, Feb 21, 2009 at 11:10 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: On Sat, Feb 21, 2009 at 8:53 PM, André Thieme splendidl...@googlemail.com wrote: On 21 Feb., 18:24, Mark Volkmann r.mark.volkm...@gmail.com 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 this macro to also accept an integer as the first argument instead of a binding vector for cases where the number isn't needed in the body. I don't find this very interesting. There several variants of how dotimes could be, but the one that we currently have is the one that is used since a few decades in Lisp, and it is the one that makes very much sense. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) (print Santa saysHoHoHo) How often do you really want to repeat the same side effect many times in a row? Why does it hurt to just say (dotimes [i 100] ...)? This will not reduce readability dramatically, but is a consistant use of dotimes. It also does not reduce productivity. Why make a breaking change for this? Why do you say it would be a breaking change? I just got the following to work with minimal changes to the dotimes macro. (dotimes 3 (println Ho)) (dotimes [n 4] (println n)) So both forms work with a single macro definition. Here's what I did. 1) Wrap the body of the macro inside the following: (let [new-bindings (if (integer? bindings) ['n bindings] bindings)] ... ) This creates the required binding when only an integer is passed and using the supplied value for bindings otherwise. 2) Change every occurrence of bindings in the body to new-bindings. 3) Move the (defmacro dotimes ... ) to just before (defn make-array ...). That's the first time it's used in core.clj and it will not be after the definition of integer?. Is there a reason to not make this change? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: dotimes suggestion
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 r.mark.volkm...@gmail.comwrote: On Sun, Feb 22, 2009 at 1:34 PM, David Nolen dnolen.li...@gmail.com 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?) allow for multiple types to be passed into a function. On top of that it's trivial to produce a macro on top of dotimes that does what you want that doesn't spend time checking the type of it's argument. Really my main goal is to make Clojure code as easy to read as possible. In this particular case, I think code like this: (dotimes [n 3] (println knock)) leaves the reader wondering What is the n for?. Someone suggested this: (dotimes [_ 3] (println knock)) That still seems like too much to read for what I'm getting. OTOH, (dotimes 3 (println knock)) isn't likely to confuse anybody. Sure, I could get what I want by writing my own macro. The problem I have with that is that I don't want to litter my code with calls to custom macros that readers of my code have to figure out. I prefer to use functions that readers will already be familiar with unless introducing my own macros is going to significantly shorten the code. On Sat, Feb 21, 2009 at 11:10 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Sat, Feb 21, 2009 at 8:53 PM, André Thieme splendidl...@googlemail.com wrote: On 21 Feb., 18:24, Mark Volkmann r.mark.volkm...@gmail.com 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 this macro to also accept an integer as the first argument instead of a binding vector for cases where the number isn't needed in the body. I don't find this very interesting. There several variants of how dotimes could be, but the one that we currently have is the one that is used since a few decades in Lisp, and it is the one that makes very much sense. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) (print Santa saysHoHoHo) How often do you really want to repeat the same side effect many times in a row? Why does it hurt to just say (dotimes [i 100] ...)? This will not reduce readability dramatically, but is a consistant use of dotimes. It also does not reduce productivity. Why make a breaking change for this? Why do you say it would be a breaking change? I just got the following to work with minimal changes to the dotimes macro. (dotimes 3 (println Ho)) (dotimes [n 4] (println n)) So both forms work with a single macro definition. Here's what I did. 1) Wrap the body of the macro inside the following: (let [new-bindings (if (integer? bindings) ['n bindings] bindings)] ... ) This creates the required binding when only an integer is passed and using the supplied value for bindings otherwise. 2) Change every occurrence of bindings in the body to new-bindings. 3) Move the (defmacro dotimes ... ) to just before (defn make-array ...). That's the first time it's used in core.clj and it will not be after the definition of integer?. Is there a reason to not make this change? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: dotimes suggestion
On Feb 21, 9:53 pm, André Thieme splendidl...@googlemail.com wrote: On 21 Feb., 18:24, Mark Volkmann r.mark.volkm...@gmail.com 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 this macro to also accept an integer as the first argument instead of a binding vector for cases where the number isn't needed in the body. I don’t find this very interesting. There several variants of how dotimes could be, but the one that we currently have is the one that is used since a few decades in Lisp, and it is the one that makes very much sense. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) (print Santa saysHoHoHo) How often do you really want to repeat the same side effect many times in a row? Why does it hurt to just say (dotimes [i 100] ...)? This will not reduce readability dramatically, but is a consistant use of dotimes. It also does not reduce productivity. Why make a breaking change for this? I second that. In my (somewhat limited) lisp experience, you can streamline the code and make it more readable by defining an appropriate macro. In this instance, you may want to define this macro that would allow you to say: (print-times 3 ho) 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). 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. Mirko --~--~-~--~~~---~--~~ 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: dotimes suggestion
On Sun, Feb 22, 2009 at 1:46 PM, David Nolen dnolen.li...@gmail.com 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 drop. I do appreciate the use of binding forms. It's just that in this case I have to specify a binding that isn't even used ... well the value is used, but not the variable. On Sun, Feb 22, 2009 at 2:42 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Sun, Feb 22, 2009 at 1:34 PM, David Nolen dnolen.li...@gmail.com 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?) allow for multiple types to be passed into a function. On top of that it's trivial to produce a macro on top of dotimes that does what you want that doesn't spend time checking the type of it's argument. Really my main goal is to make Clojure code as easy to read as possible. In this particular case, I think code like this: (dotimes [n 3] (println knock)) leaves the reader wondering What is the n for?. Someone suggested this: (dotimes [_ 3] (println knock)) That still seems like too much to read for what I'm getting. OTOH, (dotimes 3 (println knock)) isn't likely to confuse anybody. Sure, I could get what I want by writing my own macro. The problem I have with that is that I don't want to litter my code with calls to custom macros that readers of my code have to figure out. I prefer to use functions that readers will already be familiar with unless introducing my own macros is going to significantly shorten the code. On Sat, Feb 21, 2009 at 11:10 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Sat, Feb 21, 2009 at 8:53 PM, André Thieme splendidl...@googlemail.com wrote: On 21 Feb., 18:24, Mark Volkmann r.mark.volkm...@gmail.com 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 this macro to also accept an integer as the first argument instead of a binding vector for cases where the number isn't needed in the body. I don't find this very interesting. There several variants of how dotimes could be, but the one that we currently have is the one that is used since a few decades in Lisp, and it is the one that makes very much sense. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) (print Santa saysHoHoHo) How often do you really want to repeat the same side effect many times in a row? Why does it hurt to just say (dotimes [i 100] ...)? This will not reduce readability dramatically, but is a consistant use of dotimes. It also does not reduce productivity. Why make a breaking change for this? Why do you say it would be a breaking change? I just got the following to work with minimal changes to the dotimes macro. (dotimes 3 (println Ho)) (dotimes [n 4] (println n)) So both forms work with a single macro definition. Here's what I did. 1) Wrap the body of the macro inside the following: (let [new-bindings (if (integer? bindings) ['n bindings] bindings)] ... ) This creates the required binding when only an integer is passed and using the supplied value for bindings otherwise. 2) Change every occurrence of bindings in the body to new-bindings. 3) Move the (defmacro dotimes ... ) to just before (defn make-array ...). That's the first time it's used in core.clj and it will not be after the definition of integer?. Is there a reason to not make this change? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: dotimes suggestion
On Sun, Feb 22, 2009 at 1:54 PM, Mirko mirko.vuko...@gmail.com 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 nice if those commonly used macros were already a part of the language so you didn't have to write them? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: dotimes suggestion
On Feb 22, 3:14 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Sun, Feb 22, 2009 at 1:54 PM, Mirko mirko.vuko...@gmail.com 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 nice if those commonly used macros were already a part of the language so you didn't have to write them? -- R. Mark Volkmann Object Computing, Inc. Well yes, for commonly used macros. So, dotimes is one. But how many do you want? Or with how many different calling options? print-times was a simple example. Now, if print-times starts appearing in many files and projects, you put it into your initialization file. Finally, you can start an add-on library to closure with common extension that people can download. What I learned and what I strive for is to define the language for the particular problem at hand. It is just me, but I like the challenge, and also the code is so much more readable. And I like readable code when I revisit it six months down the line. Mirko --~--~-~--~~~---~--~~ 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: dotimes suggestion
On Feb 22, 2:54 pm, Mirko mirko.vuko...@gmail.com 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] `(dotimes [placeholder# ~n] ~...@body)) #'user/repeat-times user= (repeat-times 3 (println hello!)) hello! hello! hello! nil 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 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: dotimes suggestion
On Feb 22, 6:19 pm, Raffael Cavallaro raffaelcavall...@gmail.com wrote: On Feb 22, 2:54 pm, Mirko mirko.vuko...@gmail.com 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] `(dotimes [placeholder# ~n] ~...@body)) #'user/repeat-times user= (repeat-times 3 (println hello!)) hello! hello! hello! nil user= Uh, it will take me time to get used to the brackets. But if I managed to learn some Lisp at my late stage of life, I guess I will learn to handle brackets as well :-) Thanks, Mirko --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
dotimes suggestion
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 first argument instead of a binding vector for cases where the number isn't needed in the body. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: dotimes suggestion
+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 For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dotimes suggestion
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 timothyprat...@gmail.com wrote: +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 For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dotimes suggestion
(defmacro again [n body] `(dotimes [~'_ ~n] ~...@body)) (again 3 (println Ho)) On Sat, Feb 21, 2009 at 5:51 PM, samppi rbysam...@gmail.com 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 timothyprat...@gmail.com wrote: +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 For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dotimes suggestion
On Sat, Feb 21, 2009 at 5:01 PM, David Nolen dnolen.li...@gmail.com wrote: (defmacro again [n body] `(dotimes [~'_ ~n] ~...@body)) (again 3 (println Ho)) On Sat, Feb 21, 2009 at 5:51 PM, samppi rbysam...@gmail.com 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 timothyprat...@gmail.com wrote: +1 I see a theme here. There are many Clojure functions that take an argument that must be some kind of sequence where it is frequently the case that only a single value is needed. Is the main reason that these don't support passing either a single value or a sequence that the overhead of checking that would hurt performance? Here's another example where this theme makes the code look a bit complicated. (use '[clojure.contrib.str-utils :only (str-join)]) It would be great if this could be written as (use '[clojure.contrib.str-utils :only str-join]) or even (use 'clojure.contrib.str-utils :only 'str-join) It's not clear to me why the use function couldn't figure out what to do with these simpler arguments. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: dotimes suggestion
On 21 Feb., 18:24, Mark Volkmann r.mark.volkm...@gmail.com 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 this macro to also accept an integer as the first argument instead of a binding vector for cases where the number isn't needed in the body. I don’t find this very interesting. There several variants of how dotimes could be, but the one that we currently have is the one that is used since a few decades in Lisp, and it is the one that makes very much sense. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) (print Santa saysHoHoHo) How often do you really want to repeat the same side effect many times in a row? Why does it hurt to just say (dotimes [i 100] ...)? This will not reduce readability dramatically, but is a consistant use of dotimes. It also does not reduce productivity. Why make a breaking change for 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: dotimes suggestion
On Sat, Feb 21, 2009 at 8:53 PM, André Thieme splendidl...@googlemail.com wrote: On 21 Feb., 18:24, Mark Volkmann r.mark.volkm...@gmail.com 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 this macro to also accept an integer as the first argument instead of a binding vector for cases where the number isn't needed in the body. I don't find this very interesting. There several variants of how dotimes could be, but the one that we currently have is the one that is used since a few decades in Lisp, and it is the one that makes very much sense. For example, (print Santa says) (dotimes 3 (print Ho)) (.flush *out*) (print Santa saysHoHoHo) How often do you really want to repeat the same side effect many times in a row? Why does it hurt to just say (dotimes [i 100] ...)? This will not reduce readability dramatically, but is a consistant use of dotimes. It also does not reduce productivity. Why make a breaking change for this? Why do you say it would be a breaking change? I just got the following to work with minimal changes to the dotimes macro. (dotimes 3 (println Ho)) (dotimes [n 4] (println n)) So both forms work with a single macro definition. Here's what I did. 1) Wrap the body of the macro inside the following: (let [new-bindings (if (integer? bindings) ['n bindings] bindings)] ... ) This creates the required binding when only an integer is passed and using the supplied value for bindings otherwise. 2) Change every occurrence of bindings in the body to new-bindings. 3) Move the (defmacro dotimes ... ) to just before (defn make-array ...). That's the first time it's used in core.clj and it will not be after the definition of integer?. Is there a reason to not make this change? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
