Design/Implement 'Slicing' mechanism

[epeguero]

Cool; these are useful proposals! To break it down point by point:

First, I'd like to pattern match on the group which will run the code. In this example, on t.top_half.row[1].col[y]

Totally makes sense to me; this is totally the way to do it.

f : A[n_a][m_a], B[n_b,m_b] -> C[n_c, m_c] =
[...]
To compute these data slices, I need to bind variables over the size of the input arrays (in this example: n_a, m_a, ... etc)

I think I understand what you're getting at here with the "type signature" for the function—it's less about declaring the inputs and outputs and more about just binding variables to their sizes so you can manipulate the ranges of the underlying arrays.

From a somewhat aesthetic perspective, however, I think it's a little weird to "declare" a "function" with "arguments" when those arguments are really globals by design that should be accessible everywhere. Put differently, the declarations of A and B and C reside elsewhere (namely in the data section, because these declarations are big and complicated), so it looks a little counter-intuitive to "declare" them again here as arguments.

Of course, you could make the argument that these declarations amount to restrictions on which globals a given function can touch, which makes the function easier to understand locally. But it's worth acknowledging that somewhat exotic semantics clear.

Finally, it's nice to operate on arrays with zero-based indices, so we bind the max dimension sizes to the code block rows_a, cols_a, ..., and let the compiler deduce the obvious mapping.

I really like this idea of declaring "slices" to make iteration easier! The loops now get to look like "iterate over this entire logical array" instead of "iterate in this funky pattern over part of the array." I'd submit that a more natural way to do this would be to declare new names just for the slice, rather than reusing the same name as the underlying array, something like this:

let A_slice = A[1][0:y/m_a]
[...]
A_slice[0]  # The first element of the above range.

For the sake of incremental progress, I propose that we don't need to do all these features at once. It's possible to have a working system at each step and to make iterative refinements by taking these steps, for example:

1. Pattern-match on the group that runs the code. What you do with those bound variables is totally up to you; you can even just printf them if you want.
2. Add a mechanism for declaring these "slice" things that make iteration more convenient. But calculating these indices might still be sort of inconvenient.
3. Finally, we can make that mechanism for slicing more convenient by letting you bind names for array sizes or whatever.

How does that sound?

Originally posted by @sampsyo in #24 (comment)