...

...

"SIGOURE" == SIGOURE Benoit <sigoure.benoit@lrde.epita.fr> writes:

Major changes: new way of handling arrays. The whole way of handling arrays in XRM has been changed. The former way of doing it was somewhat simplistic and quickly reached its limit. We used to have: x[1][2] represented as ArrayAccess(x, [1, 2]), we now have: ArrayAccess(ArrayAccess(x, [1]), [2]) which means that the expression is parenthesized as (x[1])[2]. Pretty much like in Java/C/C++... So far it did not make sense to have this approach since one cannot access the intermediate dimensions anyway (eg: if x is a 2D array, say: x[3][3], it doesn't make sense, in XRM, to access x[2] for instance). We are moving to an approach which is more Java/C-like because we want to be able to write things such as: x[1..3,5,7..9][1,3,5][2..6] which is suddenly more complex than what we used to support before. This revision provides several new features among this new way of writing array accesses: It is now possible to declare an array using ranges, eg: x[1..3,7][2..4] will declare a 2D array defined only for certain ranges (it's somewhat like sparse arrays) It will soon be possible to write equality tests such as: x[1..3][2,3]=0 to check whether x[1][2]=0 & x[1][3]=0 & x[2][2]=0 etc. Other new operators added in the grammar (but not yet implemented): x[1..3][2,3]?=0 is there at least one of the elements that's equal to 0? x[1..3][2,3]?!=0 same but at least one not equal. Array declarations have been optimized since the declarations are now directly generated instead of creating a meta-for loop that will be later unrolled to generate them. This also introduces a problem (see the TODO).

Nice and well documented: congrats!