[Gambas-user] Wrong error message

[Doriano Blengino]

Doriano Blengino ha scritto:
> Benoît Minisini ha scritto:
>   
>>> Benoît Minisini ha scritto:
>>>     
>>>       
>>>>> Hi!
>>>>> There's minor bug.
>>>>> Overflow with concatenate operator causes wrong error message.
>>>>> You can reproduce the bug with this code:
>>>>>
>>>>> Dim ii As Integer
>>>>> Dim jj As Integer
>>>>>
>>>>> For ii = 9 To 0 Step -1
>>>>> jj&= ii<--- Wanted Integer got String instead.
>>>>> Next
>>>>>
>>>>> Gambas 3 rev 2879 @ Ubuntu 9.10 64bit
>>>>>
>>>>> Jussi
>>>>>         
>>>>>           
>>>> I'd like to know what you expected exactly from that code, and what you
>>>> think the error message should be!
>>>>
>>>> For information, the previous code is equivalent to:
>>>>
>>>> Dim ii As Integer
>>>> Dim jj As Integer
>>>>
>>>> For ii = 9 To 0 Step -1
>>>>
>>>>    jj = CInt(CStr(jj)&  CStr(ii))
>>>>
>>>> Next
>>>>
>>>> The error message comes from CInt(). When its argument cannot be
>>>> converted to an integer, it just says that there is a type mismatch (you
>>>> forgot to tell that) and that its argument is not an integer.
>>>>       
>>>>         
>>> I think that Jussi is right. Even the form you are using shows that the
>>> "&" operator is used with an integer to the left, and so, the "&" is
>>> meaningless. This is even more true with the C-style operator "&="
>>> which, by definition, must not cast the operand to the left.
>>>       
Errata corrige.
It seems I must drive my car to better understand gambas... interesting...

Ok, now I understand the two code snippets above. The net result should 
be an integer having value 9876543210. Apart from the fact that a simple 
assignment does the same work, which leads me to think that Jussi wanted 
something else, I am still not convinced about the casting (or, better, 
conversion) while writing to variables.

I feel something weird in using an integer variable as if it was a 
string, and the above snippet does that.

I wrote the same code and tried it - "wanted integer got string 
instead". Then I traced the code, and discovered that the conversion 
fails because an overflow, but the resulting error says something else 
(I can understand why).

Well, what to say? I don't like the automatic conversion while writing, 
but I am not sure. The more the language does things by its own, the 
more you can get confused - anyway we don't want a stupid language you 
must say everything to, right?. The routine I tested is:

PUBLIC SUB Form_Open()
  DIM i, k AS Integer
 
  k = 9876543210
  k = 0

  FOR i = 9 TO 0 STEP -1
    ' k &= i
    PRINT "k="; k, "i="; i
    k = CInt(CStr(k) & CStr(i))
  NEXT
END

The first assignment "k = 9876543210" is silently accepted by both the 
compiler and the interpreter, and is wrong. Apparently, gambas does two 
different things while parsing a source and converting a string to an 
integer at runtime; at last, I see two things that could be corrected 
(incorrect constants and "not a string" instead of overflow).

Regards,
Doriano