I don't think passing symbols around and having special case behavior scattered around different functions is going to help beginners. If anything, it would confuse them when they try to treat .methods as first-class functions in their own code and discover that it doesn't work.
-Per On Fri, Mar 19, 2010 at 3:10 PM, LauJensen <lau.jen...@bestinclass.dk> wrote: > 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.
