Where would you place the type hint needed to avoid reflection ? 2010/3/19 LauJensen <lau.jen...@bestinclass.dk>: > Konrad, > > Im not following where this would be a problem in terms of > optimization. In the definition for map, > all that needs to be added is a check for a symbol? and the resulting > sequence could look and act > exactly like it would, had you manually added the #(.method %) right? > > If the technical obstacle can be overcome, which Im confident that it > can, then regarding semantics > this have come up several times, where people intuitively assume that > it works, which I completely > understand and think it should, so it wouldn't be adding a layer of > complexity. > > Lau > > On 19 Mar., 08:46, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: >> On 18 Mar 2010, at 16:55, Per Vognsen wrote: >> >> > Is there any reason why a .method occurrence in non-operator position >> > doesn't just do the closure wrapping automagically? >> >> There is two reasons I can think of, though of course I can't know if >> they are the real ones. >> >> First, a technical reason: .method is handled as part of macro >> expansion: >> >> user> (macroexpand-1 '(.hashCode 3)) >> (. 3 hashCode) >> >> The result is a special form for Java interop. Symbols in non-operator >> positions are not macro-expanded, so some other mechanism would have >> to be invented to handle them in a special way. It would in fact >> create a first "special symbol" category, complicating the semantics >> of the language, so this is not just a technical reason. >> >> Second, a semantic reason: Java method calls are resolved statically >> if possible (you can use reflection warnings to find out where this >> fails), making them very fast. Creating and calling a closure is a >> much slower operation. Rich has stated at several occasions that he >> considers performance in important part of the interface of a >> function, so making a clear syntactic distinction between a fast and a >> slow operation would fit well with that point of view. >> >> Konrad. > > -- > 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 > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. >
-- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
