On Fri, Mar 19, 2010 at 4:04 AM, Per Vognsen <per.vogn...@gmail.com> wrote:
> 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.
This has been discussed some, including alternate hinting
syntaxes not entirely unlike what you suggest:
http://clojure-log.n01se.net/date/2010-01-21.html#08:34
--Chouser
http://joyofclojure.com/
--
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.
