Interesting. It seems our views are similar on some aspects of this and divergent in others. I agree with you that the cell-based referencing system that treats every individual datum independently is too low-level and can lead to arbitrary spaghetti. (Boy do I know that spaghetti. I have been doing battle with that spaghetti. Or more precisely, with the computational model that you correctly describe as allowing for spaghetti.) There is clearly a need to express operations at a higher level: on vectors of data, let's say, rather than arbitrarily cell-by-cell. On the other hand, the grid layout and cell referencing system are the essence of the spreadsheet. If you mess with it very much, you forfeit the familiarity of spreadsheet users and run the risk of forfeiting what makes spreadsheets so accessible and popular in the first place. So I see the challenge less as "how to come up with a more structured UI that maps to a more coherent dataflow model" (where by "coherent" we mean literally, "let related data cohere together") and more as "how to generalize existing spreadsheet language into something that allows for coherence and exploits it where possible". Although spreadsheet language allows spaghetti, most spreadsheets do lay out their data and calcs in a coherent fashion. It's just that the system fails to recognize it.
Once one achieves "coherent dataflow", there might be a case for adding some features into spreadsheets at the application level that allow for declaring and visualizing more structure. But I think it's a mistake to start with that - or at least risky, because spreadsheet users like spreadsheets and there is no guarantee they will like anything else. (There's a reason why it's always programmers who come up with ideas for "fixing" the spreadsheet UI. You gave yourself away with the Haskell reference :)) The approach I'm advocating is risky too, though, since it's not obvious that there is any coherent generalization to be had out of the spreadsheet data model.
The reason why I can't be "absolute" about it is because in Calc (and Excel the last time I used it), to extend a computation over a vector, you highlight the computation and then [...] resize it into an area parallel to the input vectors
Yes, but in your example the computation that you extended this way had an identical number in every cell. (That is, by extending it, you were copying a formula guaranteed to evaluate to the same number in every cell of the column.) If that's correct, why copy that number at all? Why not just keep it in one cell and have everyone reference it from there? Is it that you wanted it to be visually nearby in every row? I'm probably just missing something about your example.
That sounds suspicious. mean(v) should be associated with the column v in a clear way.
But the solution is to make it very easy for you to lay out your data and calculations in the way you find clear. It is certainly not to force every user to lay out their data and calculations that way.
Suppose I open up LibreOffice Calc, and my first row gets the values "c", "x", "y" in that order, as labels for three columns. The second row gets the values 2, -2, 0. The third row gets the odd formulas:
=A2, =B2 + 0.02, =B3 * B3 + A3 * B3 - 1
Now I highlight C3 and drag it up to C2 (the y=0 term which shouldn't be y=0 is now correct). I also highlight A3 through C3 and drag it down, until my x's range from -2 to +2; this happens at row 202.
The key thing is, this "dragging autofill" has quickly managed to make all of the y computations dependent on the same c, whose authoritative value is stored at cell A2. (I can also change what x's I look at by tweaking the cell B2.)
So I highlight the x and y columns, click the Chart button, to do a scatterplot, lines only -- no point markers. Then I need to kill the autoadjustment of the y axis because it will confuse me, so I set it to go from y = -5 to +10.
Now I can just start modifying this parameter c in cell A2, and see how the graph changes. I might notice for example that the vertex of the parabola hits a maximum when c = 0. That's an interesting feature; it suggests that the vertex of the parabola describes its own parabola as you vary c. Et cetera.
The only reason for doing it this way is because that is the easiest way I know of to get the computation right for 200 data cells. You're right, I could hand-write 200 different computations to all point to A2. It would take a long time and I would hate my life. I could also write in the value "2" and whenever I want to change it, drag across 200 rows. But then I would never get to see how this thing changes. (If you've never seen it, see Bret Victor's "Inventing on Principle" talk for a discussion of the power of having a direct connection with your artistic creations.)