[CLJ-701] Compiler loses 'loop's return type in some cases Created: 03/Jan/11 Updated: 21/Jul/14
|Fix Version/s:||Release 1.7|
Clojure commit 9052ca1854b7b6202dba21fe2a45183a4534c501, version 1.3.0-master-SNAPSHOT
Generates the following warnings:
This is interesting for several reasons. For one, if the arg to recur is a let form, there is no warning:
Also, the compiler appears to understand the return type of loop forms just fine:
The problem can of course be worked around using an explicit cast on the loop form:
Reported by leafw in IRC: http://clojure-log.n01se.net/date/2011-01-03.html#10:31
|Comment by a_strange_guy [ 03/Jan/11 4:36 PM ]|
The problem is that a 'loop form gets converted into an anonymous fn that gets called immediately, when the loop is in a expression context (eg. its return value is needed, but not as the return value of a method/fn).
gets converted into
see the code in the compiler:
this conversion already bites you if you have mutable fields in a deftype and want to 'set! them in a loop
|Comment by Christophe Grand [ 23/Nov/12 2:28 AM ]|
loops in expression context are lifted into fns because else Hotspot doesn't optimize them.
Adressing all those problems isn't easy.
 beware of
|Comment by Alex Miller [ 21/Oct/13 10:28 PM ]|
I don't think this is going to make it into 1.6, so removing the 1.6 tag.
|Comment by Kevin Downey [ 21/Jul/14 7:14 PM ]|
an immediate solution to this might be to hoist loops out in to distinct non-ifn types generated by the compiler with an invoke method that is typed to return the getJavaClass() type of the expression, that would give us the simplifying benefits of hoisting the code out and free use from the Object semantics of ifn