It seems to me that there is mainly 2 categories in this thread: - people that are worried about the difficulty to understand and to code with the throw-on-overflow semantic. They worry about untested cases showing in production code and the steeper learning curve of the language. (I am not of this side, so please forgive me if I don't understand the argument well enough)
- people that are annoyed to lose some speed everywhere in programs, in a way that can't be easily profiled or solved without annotating every lines. People that also believe it is rare and predictable to overflow a long. I think both arguments are valid, and that most people won't change their mind on this subject. In consequence, I would like to advocate a proposal along the lines of: - A set of operations per return size, labelled by their size. +-long, +-boxed, +-float,+-double ... (I am not good with name, so I am sure other people can come with better names) . They are overloaded on their arguments, but indicate return size (I think that's what the last branch does, but then again I might be totally wrong). - A set of operation without annotations : +, - ,... By default, these operators map to +-boxed, --boxed,... This solves the worries about the steep learning curve, because for beginners the story stops here. There is a flag allowing to change the default value, (or a namespace trickery, but it make it harder to apply to library code). That should come with some coding convention: - use +-boxed when you write a function that creates int exponentially bigger that its argument. (fact is in this category) - use +-long when you write code abound integers bound to a resource (indices, counters and the like...) - use the untagged operators in the other situations, +-boxed when in doubt. I would also advocate that there should be a +-small family that is either +-long or +-int depending on the platform. (+-long on modern computers, but open the way to +-int on phones, or +-double on Javascript platform where there is no integer, if I am no wrong.) For those worrying about a semantic-changing flag, I would like to note that it is not semantic-changing, it is only resource-size changing. You answer the question : what is the size of an integer? It is not different than choosing your heap size. If you don't have enough resource there is an exception (not a silent failure, so this is safe) and you can add more resources. I like this because: - it gives a clear story for beginners - it gives an easy way for people having very important production code (like a server), that does not need very high performance - it gives an easy solution for people having some code that need higher performance - it paves the way for other platforms - it is a pay-as-you-go approach, you don't have to understand any of that before you need it. What do you think? -- 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
