3

I have a small question about how the Mathematica frontend colours in the variables that appear in (wrongly written) iterators. More specifically, I'm intrigued by the colour of the third x in iterators of the form

Table[x, {x, 0, x}]

which, as shown here, matches the first and second ones.

This colouring of variables that are being iterated over is a very helpful feature in getting the iterators right and not using variables outside of their domain of definition; for example, the colours in

x Table[x, {x, 0, 5}]

make it abundantly clear that the x inside the Table will evaluate to a specific number, while the one outside it won't.

However, an iterator of the form shown in the first code snippet above is incorrect and will usually return an error, so the colouring should reflect that and not put it in the same colour (pale blue for me) as iterated over variables.

In a slightly more curious turn, I can think of one example where the first construction is valid, such as with

Module[{x = 5}, Table[x, {x, 0, x}]]

or simply

x=5;
Table[x, {x, 0, x}]

which indeed work, but the colour of the third x inside Table[x, {x, 0, x}] should match the first one (pale green and black, respectively, for me).

Is this a bug, or simply a curious corner case?

Svend Tveskæg
  • 425
  • 5
  • 14
Emilio Pisanty
  • 10,255
  • 1
  • 36
  • 69
  • Interestingly, the highlighting would be correct if the documentation would be right about in which order the evaluation of imax and the localization of i happened, as it is described in the documentation. But it seems both the documentation and the highlighting has gotten it wrong: http://reference.wolfram.com/mathematica/tutorial/EvaluationInIterationFunctions.html – C. E. Oct 28 '13 at 20:49

1 Answers1

6

While the highlighter could have coloured both xs differently, it is far simpler (in cases like Table, where there's structure) to identify the iterator symbol and colour every occurrence within the keyword. It would be an additional layer of complexity in the code base for what is clearly an edge case (even though valid).

If you keep looking, you'll find a lot of such quirks in the highlighter. For example, why isn't x green here (second example in the image)?

(Module)[{x = 1}, x]

Why is the second x red below even though it is valid?

DynamicModule[{x = 1}, Module[{x}, x = 2]]

In the end, the highlighter will only take you so far and should serve only as a visual guidance for scoping/errors/clarity and not be a substitute for actual knowledge of the syntax, evaluation sequence, scoping rules, etc.

I think you only meant this as an example, but in case you actually do write code like this, you might want to consider changing your style to reduce the ambiguity. It's not easy for a beginner or even an intermediate user to read Table[x, {x, 0, x}] and infer that the third x is not the same as the other two.

rm -rf
  • 88,781
  • 21
  • 293
  • 472
  • Yeah, this is only an example. I noticed it halfway through typing Table[x, {x, 0, xmax}]. Even when correct, an iterator of the form {x, 0, x} is definitely asking for trouble. Thanks for those two examples! – Emilio Pisanty Oct 29 '13 at 11:52
  • 1
    FWIW I think that we should be capturing these comparatively minor end-cases. Using the current feature set, though, implementation on WRI's end is time-consuming...too much so for the limited reward per case we capture. But I'm thinking two and three versions ahead, and I'm already laying out plans... – John Fultz Oct 29 '13 at 17:01
  • 1
    That having been said, I do think that the coloring of the DynamicModule case in the answer above is correct. Yes, the code might be correct, but it is confusing and potentially error-prone. A little-understood fact about syntax coloring is that it never colors red illegal code (except after a Shift+Enter syntax fail). Take a look. Every red coloring is legal Mathematica code. But, if we've done our jobs correctly, red coloring is an indication of buggy code on the user's part. I.e., red means you hit an antipattern which often results in the code performing not as you intended. – John Fultz Oct 29 '13 at 17:09
  • @JohnFultz Thanks for the info re: future plans. I agree that the red colour in DynamicModule + Module combo usually indicates buggy code on the user's part and do in fact consider that a useful feature. I was primarily giving a some examples of cases where the highlighter indicates something that might not necessarily correspond to the validity of the code. – rm -rf Oct 29 '13 at 17:32
  • @John I don't remember exactly where, but I have encountered in the documentation that red-colored code is simply a warning about inner scoping constructs stealing the scope of outer ones with an acknowledgement that there are valid use cases for such code. – LLlAMnYP Jun 29 '17 at 12:14