[chuck-users] Problem with mixed float int lists

[Hans Aberg]

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