On Thu, Dec 15, 2011 at 9:31 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Thu, Dec 15, 2011 at 9:23 PM, Cedric Greevey <cgree...@gmail.com> wrote: >> There is no possibility of "high performance higher order usage", >> because primitives are boxed inside of collections. Unless you >> proliferate int-vectors, double-vectors, long-seqs, and so forth and >> map-longs, filter-doubles, remove-doubles, etc., etc., and that will >> lead quickly to an unwieldy and messy API that will just leave >> everyone longing for the way things used to be. > > This isn't true,
Sure looks like it -- unless you have the runtime checking constantly what's in collections to detect all-one-primitive-type cases, which would gobble cycles and thereby defeat the purpose, or else thread static knowledge of what gets put where all through the code, which would mean either a proliferation of types as noted above, an equivalent proliferation of hints like (let [x ^long-seq s] ...), or a lot of static analysis by the compiler (with corresponding loss of dynamicness -- pretty much anything changing would require everything that depends on it to be recompiled, much, *much* worse than is already the case with direct callers of primitive-optimized fns. Regardless, you again snipped something pretty important: Furthermore, even supposing someone adds, say, map-longs, there's still a way to have the cake and eat it too. One could have all *three* versions: MangledName implements IFn, if there're few enough arguments one of the 1.3 interfaces, and has the static method. If one of 1.3 interfaces is implemented, it can be used in the hypothetical future map-longs. The four-argument limit then *only* applies to *direct* higher-order use -- that is, (map-longs f s1 s2 s3 s4 s5) would not work. If there were only four or fewer long-seqs, then f would need to have four or fewer arguments and would then be capable of having a 1.3 interface; or else f's position would be taken by a closure that invoked the real f, something like #(f %1 42 %2 %4 0.5 %3 "mumble"), in which case the call to f is static rather than higher-order (and can directly call the static optimized method of f's class) and the closure can be compiled as a function with a 1.3 interface taking four longs. -- 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
