On Sun, Oct 23, 2011 at 4:01 PM, Luc Prefontaine < lprefonta...@softaddicts.ca> wrote:
> It's simpler to use one representation to port the core. You can choose the > fastest/efficient one. You do not have to carry all these intermediate > types > with you. > There are already at least two numeric types: long and BigInt. If you want to try to be blissfully unaware of any of this, then you can use promoting math (+' and friends). Adding more numeric types to the tower doesn't seems to make things more complicated in the general case, only in the interop case, or in the case that you are trying to optimize your code because it is too slow or uses too much memory. Which is what we're talking about here. You have said before that you grant there are interop cases at the edges of Clojure, and they should be kept at the edge. What we are discussing in this thread are exactly those edge/interop cases. You would never have an int or Integer unless you asked for one or got one from some Java code. It doesn't make sense to come into a discussion about interop, and say that we shouldn't let interop determine the core of the language. This thread is not about the language core. > When doing an interop call, this is when you need to be specific. Elsewhere > I see no value in keeping this scheme. > Exactly, we're assuming in this thread that we're already at the edge doing interop, or trying to optimize our code. So any comments that assume we're not doing interop are out of scope. And with today's hardware, why stick with these data types ? To reduce > memory footprint ? > Ha ! Ha !, I used to work on computers with 256K of physical memory. > This concern was legitimate in this prehistoric era. But today ? > There are good reasons at both ends of the computing spectrum to want to be efficient with memory. Embbeded systems and mobile platforms don't necessarily have terabytes of memory to access. And on the other end of the spectrum at work, we process terabytes of data using byte arrays and byte streams, if we all of a sudden needed 8 times the memory to do the same job, it would probably be a deal killer. Similarly, we have some native JNI libraries we use that limit us to using a 32-bit JVM on some of our nodes, and we are constantly fighting OOMEs in those restricted heaps. Which is an interop case, which is the context of this thread. The core of the language can use only longs, which is fine. > If you need bit manipulation in Clojure, better write a lib for this than > mangling with > these data types. > I'd rather write that code in Clojure than Java and use it from Clojure (if that's what you're saying). And if I'm dealing with data formats, (c.f. the gloss library) it would be really inconvenient to always have things converted to longs on me. I prefer to not have a language/platform that thinks it knows what is better for me, than I do. Paul -- 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
