I find these compromises quite
acceptable. Tuning code has always
been a last step in most dev. projects
I worked on except a few and I worked
on many resource constraint
platforms.
All languages I encountered had a
"default" integer/float implementation
and getting away from it rarely
occured but was doable if needed
either through some coding
trickery or compilation flags.
The mass majority need a simple
approach/implementation and this
proposal meets this requirement.
Having to care about the number sizes
is not the first design concern.
As for callers using the default implementation, some API trickery could
allow them to call a library using a
different implementation and get
return values in a compatible way
if it makes sense.
Specialized libraries could still force
callers to use the same implementation if you really need the same
performance or
precision in you own code.
For specialized arithmetic implementations,
I find the namespace approach
interesting. It may prove valuable
since at a glance the implemtation
chosen by any piece of code
would be pretty obvious.
Changing from one implementation
to another one could possibly be
easier to do with this approach.
Swapping the name space or adding
one to overload the default one
is quite practical.
The line by line annotation is a
painful approach to such changes and
should be only required in rare cases
(mixed operand computations ?)
Luc P.
Sent from my iPod
On 2010-06-20, at 6:39 AM, Nicolas Oury <nicolas.o...@gmail.com> wrote:
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
--
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
