>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)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!
