Multi-dimensional arrays.

Here's a diff to boo.g to add support to the parser to recognize mutli-dimensional arrays. Possible thank's to bamboo's redefinition in of the AST to better accomodate this.

Now when you compile:
b = Test2.ReturnIntArray()
print (b[1:1,0:1])

(Where Test2.ReturnIntArray() is some method written in C# to return a Object[,]) you get a nice message:
/home/peter/Array.boo(5,9): BCE0031: Language feature still not implemented: multi dimensional slicing.

Will work on the actually handling of MD arrays soon.

Is the macro array(Type, dimension_1_size, dimension_2_size, etc) agreed upon as a good syntax for MD arrays?

The following small patch enables using the following code:

b = array(object, (2,2,3))
print(b.GetType())

which outputs:
peter@gonzo peter $ MONO_PATH=/home/peter/svn/boo/build/ mono Array.exe
System.Object[,,]

I had to leave in the existing public static Array array(Type, length) as otherwise i was getting some booi build problems. Maybe related to how boo handles the "params" type method signitures. Not too sure on that part.

Should we try to make that work better, or does the above syntax suit people? Now that i see it, i kind of like that syntax, but i'm open to disagreement.

Shouldn't there be syntax for declaring multidimensional arrays?
Here's what I suggest: (int^3) for int[,,], (string^2) for string[,] etc.
And what about array literals? Currently ((1,2,3), (4,5,6)) represents a 2d jagged array. There should be alternative syntax for rectangular arrays.

Rodrigo and I were discussing this very issue yesterday, and had come up with (int,3) type syntax, knowing full well that this was sub-optimal, and we could change it later. I for one think that your suggestion is excellent, and easily gets across the information with little confusion.

I've done a lot of work on this so far (with lots of help from bamboo) and will hopefully have a prelim patch with this support in the next week or so (including support for the syntax you suggest).

I like (int,3) better than (int^3) - why introduce a new operator just for this?

a as (int,3)

works for me.

We can reserve ^ for XOR

If comma is suboptimal (not sure why?) then how about (int*3) which gives the flavor of an int multiplied or extended in 3 directions.

Ok, this patch supercedes the previous two patches that were just fragments. Here's what does work (but of course needs testing):

1) Creation of rectangular arrays of arbitrary rank and type.
2) Assign and retrieve from arrays
3) Assign and retrieve from a DefaultMember accessed by multiple indices. e.g:
[DefaultMember("Items")]
class Col:
_objects = array(object, (2,2))

Items (x as int, y as int) as object:
get:
return _objects[x,y]
set:
_objects[x,y]=value

col = Col()
col[0,0] = 1
print(col[0,0])

Working, but needs more testing/errorchecking/love:

1) retrieval of complex slices of arrays in N dimensions (e.g.: c = a[0:3,2:4,5:6])

Things that don't work yet:

1) array indices of negative numbers (e.g a[1,3,-1])
2) Assignment to members with several indices. See arrays-29.boo for the test case, and what fails. Need to figure out why this is happening.
3) Assignment to complex rectangular array slices (e.g a[0:1,2:3] = b[2:3,5:6])

Questions I have for further work:

1) The following code prints "tr":
a = "strings"
print (a[1:3])

Why does this print items 1-2, not 1-3? (maybe this is some convention from python i don't know (i'm not really a python coder)). My current rectangular array slicing considers "0:1" to mean "elements 0 through 1 inclusive" for each dimension. Should this change?

2) The problem with array-29.boo test seems to be a result of the lines in ProcessMethodBodies.cs:
if (AstUtil.IsLhsOfAssignment(node))
{
// leave it to LeaveBinaryExpression to resolve
Bind(node, member);
return;
}

Removing the call to Bind() makes things just bomb though. See the booc -vvv output of compiling arrays-29.boo for where this Bind() seems to screw things up or something. Pretty lost on this problem though.

Ok, there it is so far. Comments? Bugs? Flames? Recipes for apple pie?

Forgot to mention one thing:

Currently this patch causes arrays-23.boo to fail, as it creates an array() override with the signature array(Type type, params int[]). Unfortunately, i've yet to actually figure out how to make boo code then understand "array(int, 1,2,5)" and it still requires "array(int, (1,2,5))" to work.

I believe there's already a different issue open regarding solving this var args issue.

here's a new version of the patch. What's fixed/implemented with this version:

1) Settings MD slices, e.g:

a = array(int, (3,3,3))
a[0:2,0:2,0:2] = array(int, (2,2,2))

2) Retrieval of MD arrays is now non-recursive (my head hurts)
3) Fixed a problem that was present in the current code where trying to do "m.Item[x]=1" was broken but "m[x]=1" worked (if you had the right setup with DefaultMember, etc).
4) Add an ArrayTypeReference now with rank. This currently has a few problems i'm not sure how to address.
a) You can't put "_foo as (int^2)" before a constructor or method declaration, as _il won't yet be defined. Code needs to be refactored somehow to avoid this
b) If you add a decleration as above, an exception is generated about 1 member being left on the stack. I think it's the "2" for the array rank being left around, as the type left on the stack is an Int32.

Generally, I am very happy with this patch except for the above ArrayTypeReference issue, and the failure of arrays-23.boo due to the "array()" builtin not working with a variable number of arguments (requiring array(int, (2,3,4)) to create an array of rank 3)

Thoughts?

I like (int,3) better than (int^3) - why introduce a new operator just for this?

a as (int,3)

works for me.

If comma is suboptimal (not sure why?) then how about

a as (int*3)

which gives the flavor of an int multiplied or extended in 3 directions

Ok, I would consider this the final version of this patch.

Both setting and getting works for arrays, including rank collapse (i.e a = b[0:1,0:3] vs a = b[0,0:3] (one returns an array of rank 2, the other of rank 1)). I've abandoned using Array.Copy altogether, because testing showed it to be considerably slower than an item by item GetValue/SetValue. Multi indexed accessors works, etc. The type references is implemented as "as (int,3)" meaning "an int array of rank 3" for now; I still don't know what the final verdict on this one is, but it's an easy change.

The only problem i currently have is this breaks arrays-23.boo, as using the "array()" typed constructor doesnt's work in the "params" style yet. Not sure if this patch should wait for that to be working until support for that is working in boo or not. Opinions?