Array assignment in Brandy BASIC

[Richard Russell]

I was very surprised to discover that this code runs without error (and actually seems to work) in Matrix Brandy BASIC:

Code: Select all

      DIM a(100), a%(100)
      a() = a%()

I would have expected this to result in a Type mismatch (or equivalent) error, because the array types on the left and right of the assignment operator differ. Sophie's ARM BASIC V (at least, the version I have dated 1989) reports an error, as do all my BASICs (BBCZ80, BB4W, BBCSDL, BBCTTY).

Is this a Brandy extension (in which case is it documented?) or an accident (in which case Is it guaranteed to be safe to use)?

I can imagine circumstances in which it could actually be useful, but having looked at the code of my interpreters I don't think it would be practical for me to implement it.

[Richard Russell]

Is this a Brandy extension (in which case is it documented?) or an accident (in which case Is it guaranteed to be safe to use)?

A little experimentation suggests that it's not a deliberate feature, because it doesn't work as you would want it to in order to be useful.

For example while this works correctly (it prints 4E9):

Code: Select all

      a% = 2E9
      a = a% + a%
      PRINT a

this doesn't (it prints -294967296):

Code: Select all

      DIM a(9), a%(9)
      a%() = 2E9
      a() = a%() + a%()
      PRINT a(5)

[DDRM]

If you ask it how big the variant array is (using DIM), does it have the same number of elements as the integer array?

It may simply be taking a block of bytes, and instead of interpreting every 4 bytes as a 32 bit integer it may be interpreting 5 (8? More?) as a float?

D

[Richard Russell]

It may simply be taking a block of bytes, and instead of interpreting every 4 bytes as a 32 bit integer it may be interpreting 5 (8? More?) as a float?

No, because if you simply transfer one array into another (with no actual array arithmetic taking place) the indexes / indices line up:

Code: Select all

      DIM a(100), a%(100)
      a%(50) = 76543
      a() = a%()
      PRINT a(50)

This prints 76543 which wouldn't be the case if there was a misalignment of the kind you suggest.

But if the right-hand-side is an array expression it doesn't work as you would hope: it seems to coerce the result to the data type of the source array before copying it into the destination array. So if you do this:

Code: Select all

      DIM a(100), a%(100)
      a%(50) = 76543
      a() = a%() * a%()
      PRINT a(50)

it gives a 'Number is out of range' error when of course 76543^2 isn't out of range for the destination array. Put another way, it behaves as though internally it's doing this:

Code: Select all

      DIM a(100), a%(100), tmp%(100)
      a%(50) = 76543
      tmp%() = a%() * a%()
      a() = tmp%()
      PRINT a(50)

which of course largely negates the potential value of the result array having a larger range than the source array(s).