On Tue, Dec 7, 2010 at 12:58 AM, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > On 06.12.2010, at 22:35, Ken Wesson wrote: > >>> I'd say what Java needs is not complex numbers as a value type, but a way >>> to define additional value types. Complex numbers are just one >>> applications. Another one is points (2D or 3D) for geometry and graphics. >>> >>> Unfortunately the problem is not just Java, but the JVM, meaning that >>> Clojure inherits the problem. >> >> Clojure does not inherit the problem, if you use macros cleverly. You >> can stack allocate individual primitives, separately, e.g. >> >> (let [x (int 3) y (double 4.2)] >> ...) >> >> And with macros you can wrap that in an abstraction that looks like a >> single object, such as a point or a complex number. Passing it to a >> function would require a bit of magic, though -- say, bundling the > > That's exactly the problem. An abstraction that doesn't pass a function > boundary is of little use in a functional language. Decomposing complex > numbers or points into primitives can be used as a local optimization > technique, but not in a larger-scale design for software systems.
First of all, the abstraction does pass the function boundary if the function's a closure and you get it from the lexical scope rather than passing it as an argument. Second, macros can probably be used to make passing them as arguments and returning them transparent to the coder, in a way that boils away to nothing when the -server JIT goes to work on it. I can try to code a rough draft of such a facility and post it later. -- 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
