Unexpected behaviour from Table[]

Question

1. The following code in Mathematica 11:

   iList = {i, -10, 10, 2};
   Table[i, iList]
   

   produces this result:

   {i, i, i, i}
   

2. Where in version 10 (and presumably earlier versions) it produced an error:

   Table::itform: Argument iList at position 2 does not have the correct form for an iterator. >>

Note that WRI have stated in an email to a colleague that the code in 1, is not valid syntax.

Can we consider this a bug?

Answer 1

This is just a long comment trying to shed light on where the problem may be coming from.

Since version 10.2, the following is valid syntax:

Table[x, 5]

Before we could only use

Table[x, {5}]

or

Table[x, {i, 5}]

This implies that we should expect the following to work too:

n=5;
Table[x, n]

the same way as Table[x, {n}] or Table[x, {i, 1, n}] work too.

As @Kuba pointed out, it seems that when n is not set to a number, but to a list, Table uses the length of the list as the number of times to repeat.

Even in version 10.4.1, we get

n = {1, 2, 3};
Table[x, n]

(* {x, x, x} *) 

n = {y, y, y, y, y, y};
Table[x, n]

(* {x, x, x, x, x, x} *)

What could the reason be?

The simplest explanation is that Table[expr, n] maps directly to Table[expr, {i, n}]. You'll notice that the following form is valid too:

Table[expr, {i, {val1, val2, ...}}]

i will simply take val1, val2, ... in turn.

And this is exactly what seems to be happening here. The mapping to the Table[expr, {i, n}] form is carried out even if n is a list. This seems incorrect because Table[expr, n] is documented only for the cases when n is an integer.

My personal conclusion, which others may disagree with, is that it was a bad idea in the first place to allow the syntax Table[expr, n] when we already had the equally short Table[expr, {n}]. Allowing this has created ambiguity in the syntax. [Update: Actually, looking at older documentation, it seems that Table[expr, {n}] was replaced with Table[expr, n] as the official syntax.]

For the reasons stated above I also disagree with Wolfram Support that Table[i, iList] is invalid syntax when iList is a symbol (possibly with a value). The syntax seems valid, the question is what values are appropriate for iList?

Table[expr, {i, n}] is documented syntax and has worked for a long time when n had the value of either an integer or a list. Table[expr, n] is also documented syntax. It is implied in the documentation that in this latter case n should be an integer, but it is not at all clear that it cannot be a variable with an integer value.

---

These kinds of ambiguities in syntax do appear from time to time in Mathematica. The reason is that lists are commonly used both as part of syntax (as in Table[expr, {i,1,10}]) and as a collection of data. It would seam to me that given this situation, extreme care is necessary when designing and extending the Wolfram Language.

Another example of such an ambiguity is Lookup, which allows both Lookup[asc, key] and Lookup[asc, {key1, key2, ...}]. What if a key is a list? That is not uncommon. At least we have the disambiguator head Key.

Yet another example which appears to allow for ambiguity is Extract, where all of these forms are allowed: Extract[expr, 1], Extract[expr, {1,2}], Extract[expr, {{1}, {2}}], Extract[expr, {{1, 2}}]. Can you tell me quickly what each one does, without trying? But aside from some potential minor confusion to the user, I think that there is no problem with Extract. It is always easy to disambiguate, keeping in mind that a proper position specification is always a depth-1 list, and also thanks to the fact that Extract is not HoldAll.

One might argue that what yo observe with Table is not a bug because once we understand the rules, we can see what is happening, just like with Extract. Personally I still think that even allowing this syntax for the more complex case of Table (which is HoldAll and which localizes its iterator) was a mistake. We might as well call the decision a bug. This is admittedly a debatable, subjective opinion, so I won't tag the post as bugs.

Answer 2

The above analysis is quite correct. I also don't disagree that the decision to not require braces was questionable. I spent quite a period of time in this spring analyzing the design issues introduced by this change and how to resolve them. The basic issue is that with the list syntax, the first argument is never evaluated unless it is the only argument. This way the variable can be localized, protected from any global values (very important). All the other entries in the list are evaluated, because we need to know where to start and end. That's why a variable as an endpoint or list to take values from always worked.

Now, what about expressions with no explict list? If we first evaluate the non-list argument, we risk contaminating the variable. If we just wrap it in a list a hope for the best, we get the odd behavior described above. So we finally settled on: if the expression does not have a list structure, it must evaluate to a real numberic value. So the new behavior in 11.2 will be

In[1]:= iList = {i, -10, 10, 2};
Table[i, iList]
During evaluation of In[1]:= Table::nliter: Non-list iterator iList at position 2 does not evaluate to a real numeric value.
Out[2]= Table[i, iList]

I have also updated and clarified the documentation on this point, in particular that Possible Issues example mentioned above that really made no sense with the 10.2--11.1 behavior.

Thanks for bringing this to our attention so we can make it better, even if it took a little while for it to propogate to the right people to fix it.