Another thing that goes along is the following we got reported in the Seaside bug tracker 
(http://code.google.com/p/seaside/issues/detail?id=241). This is also something very strange:

#( 1 2 3 4 ) at: 2.2 --> 2

This problem seems to be caused by another Squeak unique-ism -- only on Squeak (I believe) is it legitimate to 
use a Float as an index into an Array.  The ANSI Standard would declare this to be an error (see Section 5.7.8.4).

(No comment was entered for this change.)

I agree that Strings should not implement arithmetic.  This only encourages bad coding.

However, I disagree about arrays.  "Lifting" binary operations on elements to the corresponding pointwise 
operations on whole arrays is mathematically respectable and really quite useful.  What is the objection?

(No comment was entered for this change.)

The problem is that the chronology classes in Pharo depend on the arithmetic of Collection to perform time 
computation.

So there is two things. We propose:
- move the arithmetic stuff in an extension package, so that if people want to use it, they can
- rewrite the Chrono stuff so that they do their computation without Collection arithmetics.

About the non integer indexes I will open a specific issue for it and put a fix only 
for that.

Process (so that people can understand how we worked):
- scan each class of Collections to identify methods in the arithmetic protocol (change this protocol to 
*Collections-arithmetic)
- in a dummy image, replace the body of each of these methods by ^ Float infinity, then launch all tests to 
identify which depend on the arithmetic behavior (only 3 tests identified) (move identified tests to *Collections-
arithmetic)

Note that we do not touched methods in WordArray:'array arithmetic primitives', primitives for KedamaPlugin.

Fixed in PharoInbox SLICE-Issue332-RemoveArithmeticFromCollections-simondenier.2

Class extension for Collections-Arithmetic in http://www.squeaksource.com/CollectionArithmetic.html