As a mea culpa for my earlier stupidity, here's a proposed solution that is semantically transparent if somewhat inelegantly brute force in its approach:
http://gist.github.com/331211 If need be, it could also define entries for :inline and :inline-entries for the auto-generated arity overloads. -Per On Sat, Mar 13, 2010 at 3:23 PM, Per Vognsen <per.vogn...@gmail.com> wrote: > On Sat, Mar 13, 2010 at 3:03 PM, Konrad Hinsen > <konrad.hin...@fastmail.net> wrote: >> On 13 Mar 2010, at 03:32, Jonathan Shore wrote: >> >>> Could + and other operators be changed to a macro mapping rather than the >>> current defn, mapping the argument list to a binary expression tree (+ (+ >>> (+ ... instead of the list style application (I'm guessing yes, not being >>> familiar with CL-style macros). >> >> This would not be a good idea for the arithmetic functions in clojure.core, >> as macros come with their own restrictions. For example, if + were a macro, >> you couldn't pass it as an argument to map, reduce, or apply. All of these >> occur very frequently. > > I wrote my reply to him before drinking coffee, so I hadn't considered > this (obvious) issue. > > Common Lisp's has compiler macros. These are macros associated with a > function which will be called only when calls to the function are > resolvable at compile time. While nicer than plain macros (as you can > still treat the function as a first-class value at run time) they are > still not semantically transparent because of the possibility of var > rebinding. > > -Per > -- 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
