On Jun 19, 2010, at 2:03 AM, Mark Engelberg wrote:
I'm confused. In the latest scheme, what is the eventual plan for handling a recur to a loop element that was initialized with a primitive? Are boxed numbers automatically coerced to the primitive? Would a long be coerced to a double, or double to long? Under what scenarios will you get a warning, and when will you get an error? I think what troubles me the most about this loop/recur issue is that the semantics of recur depend completely on whether a variable is assigned a primitive or boxed numeric type. To know what the recur will do, you must know the type of the assigned value. This has always been the case, but in the current version of Clojure, provided you aren't using Java interop, it's relatively straightforward to know. Unless the variable or literal is explicitly cast to a primitive, it's not a primitive. But now, with the advent of static functions which can return primitives, it becomes more likely to not easily be able to determine this fact. If I say (loop [x (foo 2)]...) I have no way of knowing what's going to happen when I recur. Yes, I realize that you can run the function and use warnings/errors to find out. But I find it unsettling to have a commonly used code form with semantics I can't predict just by looking at it.
Sorry for the confusion. This is a part of the design subject to change. I had temporarily eased the error here in an effort to see the usage patterns. The current warning tells you what is going on, since the compiler always knows when it is using a primitive local. Restoring the error on recur mismatch will cover all of these cases, without requiring any sophisticated analysis. If you get it wrong, it won't compile, and will tell you quite explicitly why.
The default (auto-primitives or always Objects) will follow the default for +, - etc.
It's attractive that the current proposal gives speed benefits to common cases with no additional annotation. But I personally place a higher value on being able to understand the semantics of my code when reading through it. I would prefer a version where loop requires some sort of explicit annotation on a variable if you want it to require a primitive upon recur. (Ideally, I'd probably want the annotation on the variable using a syntax that mirrors static functions, rather than the old technique of typecasting the initializer, since the whole typecasting system makes less sense now that literals and certain return values are already primitives. Unifying the syntax and semantics of using primitives in loops with the syntax and semantics of using primitives as inputs to static functions makes a lot of sense to me.)
Really? It seems tedious to me. Don't you get tired of saying int i = 42 in Java, when you know full well the compiler knows 42 is an int? I do, and Clojure is competing with languages that infer the right types without the redundancy.
Loops are unlike static function arguments, in many ways. There is no context when defining the signature of a static function, and you are explicitly creating an interface for callers. By contrast, a loop is not an interface for anyone, and all possible context is present.
Again, it is a matter of defaults, the non-default is going to have to be explicit, and you can just as easily be explicit that you want the loop argument to be an Object, either with (loop [^Object i 42] ...), (loop [i (num 42)] ...) or your (loop' [i 42] ...) idea.
Everyone who is advocating for what the other side ought to do should be aware that if the default doesn't go their way, the other side will be them.
Rich -- 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
