Hi Cedric, Your statement " A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments" does not stand given all the previous discussions about numeric optimizations and comparing optimizations found in other compiler. Look at any C compiler optimizations switches, you will find many compromises and limitations, in fact you might be bald after using them :)
Agree, the message should be clearer and need some improvement There's also a limit on the # of arguments even without the numeric optimization stuff. It's not a bug, it's a limitation. Software vendors are calling these things features but clearly this group cannot sustain the big marketing dept. needed to create the neçessary distorsion field to alter perceptions :))) Luc P > On Thu, Dec 15, 2011 at 6:05 PM, David Nolen <dnolen.li...@gmail.com> wrote: > > On Thu, Dec 15, 2011 at 6:01 PM, Cedric Greevey <cgree...@gmail.com> wrote: > >> > >> On Thu, Dec 15, 2011 at 5:59 PM, David Nolen <dnolen.li...@gmail.com> > >> wrote: > >> > On Thu, Dec 15, 2011 at 5:53 PM, Cedric Greevey <cgree...@gmail.com> > >> > wrote: > >> >> #<CompilerException java.lang.IllegalArgumentException: fns taking > >> >> primitives support only 4 or fewer args, > >> >> > >> >> But the function isn't *taking* primitives. It's only *returning* a > >> >> primitive, after taking Objects. So it obviously shouldn't produce > >> >> this error. > >> > > >> > Not a bug, > >> > >> Clearly a bug. A limitation on primitive arguments simply cannot be > >> applicable to a function with no primitive arguments. > > > > > > primitive args/return are thoroughly intertwined. You cannot separate them > > in the current implementation. > > And yet, it accepts this function definition, which has one without the > > other: > > (defn foo ^long [x y] (+ x y)) > > > So it's not a bug, it's a limitation (and I one I don't see how to > > > surmount). > > I don't see any logical reason why a function taking only > non-primitive arguments cannot have a primitive return value. > Certainly a Java method can take only reference type arguments and > have a primitive return value, so we're not seeing a JVM limitation > here. And all of that is leaving aside the fact that the error message > claimed that the function *did* have at least one primitive argument, > even though it did not. > > In any event, the compiler barfed on input with a message that clearly > implies that the compiler should have accepted that same input. I > can't see any way of interpreting that as "not a bug". > > -- > 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 > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail! -- 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
