>> "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!