On Fri, Mar 19, 2010 at 2:46 PM, 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.
Interesting. I had tacitly assumed there was already some "special symbol" magic going on and so did not know it was a simple case of macro expansion with a little reader support. > > 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. I thought of this as well before posting. A few comments: 1. Creation: You only need to create one closure per function, once and for all; the closure does not close over anything in the surrounding scope, it's just a wrapper. 2. Calling: This is such a straightforward case of inlining that HotSpot will eat it for breakfast. Clojure is full of idioms that would be death to performance if not for such behavior from HotSpot. 3. Type hinting: This is a deeper problem with first-class methods. The current manner of type hinting does not work well here. If you could write SomeClass.someMethod to refer to a specific class's method and perhaps supply further signature hints in the case of same-arity overloads, e.g. #^([Integer]) ResultSet.getObject, then this could be resolved. -Per > 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.
