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?

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.

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).

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.

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?

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.

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?

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

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?