I only know about the tab icon, because I was forced to find out why pressing the tab button sent me to the next execution group, instead of, as I was accustomed to, inserted a tab indentation. But what are your comments concerning my problems using tab indentation: Can you reproduce them?

Could you please show me the revised code. Even though I don't understand the purpose of your code, for instance what does e(...) mean?, it works fine here, giving no errors, using add instead of sum. I'm running Maple 11, if that is an issue.

Your second paragraph, in which you explain the difference between A and B, luckily is consistent with what I thought was the reason. So my mind is (slowly) coming around. You see, I've had no formal programming education, being a self-taught person, so these more subtle (at least to me) issues are new to me.

Try with add(...) instead of sum(...).

On a saturday morning I'm fooling a bit around in order to get better acquainted with these evaluation issues. Just as the original problem came as a complete surprise to me, the behaviour of the following code surprises me too:

A := Vector(2,(i,j) -> Matrix(4,4));
B := Vector(2,fill = Matrix(4,4));
evalb(A[1]=A[2]);
evalb(B[1]=B[2]);

In A the entries refer to different objects, whereas in B they don't. Is that really appropiate? Anyway, I know for sure that I have to look through various codes and packages of mine to eradicate the use of fill.

Thanks for your feedback. I'm using Windows. Are you aware that in Maple 11 you can toggle (clicking the button next to the help icon button) between the tab-behaviour you are experiencing (moving down to the next execution group, if one exists), and the indenting tab behaviour which I'm using (and which was default in Maple 9.5, from which I've recently upgraded)?

Instead of the code above, try to copy-paste to a new execution group the following code with tab-indented second line:

for i from 1 to 4 do
	print ("Tabbing does not seem to work properly")
end do:

I'm unable to reach the end of the second line in the copy-pasted code in the new execution group (not even by using arrows up or down, because the second line is longer than the others), unless, as before, I manually delete and subsequently reinsert the tab-indentation. Specifically, pressing the End-button positions the cursor in front of "ly" in "properly". Are there any others experiencing this mad behaviour? And how do you cope with any such?

Thanks for your historical notes - that made most of the fog in my head disappear. I think I'll just do as the Maple developers do: never use $.

Your example, which I would write shorter as

x,y := Vector(1)$2:
x[1]:=17:
x[1],y[1],evalb(x=y);

x,y := 'Vector'(1)$2:
x[1]:=17:
x[1],y[1],evalb(x=y);

indeed seems to work. I was not aware of the need for those unevaluation quotes. Thanks for that tip. But still I do not feel comfortable about these issues. Actually, I do not quite understand why Maple has built in this potentially dangerous $-feature: Originally, I spend quite some time tracking down the problem reported in this thread.

I must admit that the finer details in how Maple evaluates certain expressions seem rather foggy to me. I've not really understood why seq(...) works whereas $ doesn't. Even though using $ is by far the most compact notation for repeating an expression, using seq(...) is also quite compact. So I think I'll just consistently use seq(...) instead of $.

Even though I find these issues quite unsettling, it's nice to know that it's not me having fundamentally misunderstood something. In the future, though, I think I'll avoid using $.

Even though your method does indeed take me to the end of the second line, it does not fulfil my needs, because to me it makes no sense that in order to go to the end of the second line I first have to go to the end of the first line and then subsequently go one line down. No such behaviour was present in Maple 9.5. There you could, as expected for any well-behaved text editor, just press the End-button if you happened to be at the beginning of the second line.

Can you do more magic?

It seems to work absolutely fine, thereby making my procedure superfluous.

It is no wonder that there is a problem; the dimensionalities of A are incompatible.