On 9 Dec 2009, at 23:03, Kassen wrote:
The rule that 'chuck' seems to use on explicit lists is to look at the first entry. If that number is without a decimal point, the list is of type int[], if has one, it is float[].
Yes, and I agree this is at times inconvenient.
It would be easy to fix: look at all entries, and set it to int[] exactly when all numbers are without a decimal point.
I disagree. I want it to be set to float when I tell it to be a float. I may want to use a list of numbers without decimals as a float. This may be because the numbers will later change, or because of member function overloading (for example with LiSa.rate() it matters a lot whether the argument is a float or int), or because I want divisions to work in a certain way.
So then you want the conversion rule of int[] to float[] in case no int[] argument has been defined. The problem is that one may define fun A f(int xs[]) {...} fun A f(float xs[]) {...} The rules I gave ensure that if both are defined, only a list where all numbers do not have a decimal point is treated as int[] and passed to the first definition. If one number has a decimal point, the whole list is treated as float[], and passed to the second function. If only the second function is defined, then I gave a second rule: the list which is int[] is converted to a float[]. So isn't this what you want? One could also think of the case where inly the first is defined. In C, float's can be converted to int's. As that may loose the decimal part in unintended ways, I think one should not have it.
As I see it array definitions are currently inconsistent with the implicit cast from int to float that we have elsewhere.
Then it would be consistent, I think. Hans