# Syntax formatting when Condition is used with Blank

Consider the following codes:

x_/;x>y
Condition[x_,x>y]
Condition[Pattern[x,Blank[]],x>y]


All the three codes are equivalent.

As we can see, in the first code, x and x_ are italicized and highlighted:

In the second code, x and x_ are neither highlighted nor italicized but x_ is black (instead of blue):

The same thing goes for the third code:

What is the reason of these diffrences?

• I guess the reason for the third one is that the syntax highlighter does not check symbols deeper than a certain level to remain fast. For the second one I could only assume that "LocalVariables" in the built-in SyntaxInformation is missing for Condition, while it is added for the operator /; . – István Zachar Aug 29 '13 at 6:23

I hope you don't mind if I answer this in a larger context and you have to read a bit. What you observe here is one disadvantage of the otherwise very nice Mathematica language. Since Mathematica follows the paradigm everything is an expression and code-is-data it is a mess when it comes to features that help programmers to write correct code or make development easier. Let me explain this with a simple example. When you write a simple for-loop in Java then it will probably look like this

for(int i; i<100; i++) { /*..*/ }


For an IDE which wants to highlight the iteration variable i everything is pretty easy, because the form of a for-loop is (almost) fixed. In Mathematica the situation is not so easy, because it is not unusual that code will look very different from what it will finally be evaluated to. Let me use Table as example (because For is not highlighted at all). I'll give only the front end output so that we all see the highlighted code

As you see the localised x is highlighted properly. When we look at the evaluation chain of Mathematica we see that one of the first thing that happens is that the Head of an expression is evaluated. In our case this means that the symbol Table is evaluated to Table because it cannot be evaluated further. Lets change this in the most simple way I can think of by parenthesising it

As you see the highlighting is gone and you have the right to ask why. Why doesn't Mathematica know that this is equivalent to a normal Table call. The reason is, that Mathematica consists of two parts: The most important part is the Kernel which does all the computations for you. The Kernel would know that this is indeed a usual Table but no one asks the Kernel because the highlighting and most other fancy user-interface stuff is done by the Front End, which is the second part.

Both parts, the Kernel and the Front End do understand the Mathematica language which means, they can parse it and they know whether an expression is syntactically correct. The difference is, that only the Kernel evaluates expressions which means it reduces the input with the rules it knows. Therefore, the highlighter in Mathematica only looks at the expression an if it matches some lets call it template, it can colorise important parts for you. Important is, that the Front End is not able to evaluate code to see the real expression.

If you have understood this, than you can think of one thousand and one ways to trick the highlighter. Let me make a small gallery: The obvious example to show that highlighter cannot evaluate f to Table to make colorise the code correctly.

It doesn't even know, that List is {}

The next one is perfectly correct code because missing values in a sequence of arguments are assumed to be Null. Try to evaluate it

You might say, what the heck, I would never write it like this, I would just write Function[#+#], then I say: very well, but what when the function needs attributes which are supplied as 3rd argument? Then you need the Null as first argument. Then you say, OK, then just write it explicitly, then I say: Very well then, lets confuse us a bit more:

Now guess, what's the argument of the anonymous function here ;-) Other examples I could think of are

Bottom line is, the reason why the highlighter does not work correctly in your case is because it will only highlight instances of Condition where you use the infix operator /; and the usual form of patterns with underscore. Nothing is evaluated and therefore, the equivalence of certain other forms are not known to the highlighter.

• Perhaps the highlighter people thought that when you use the full form of Condition, Pattern, Blank, RuleDelayed, etc, you are probably more likely trying to build code at runtime. +1 – Rojo Aug 29 '13 at 18:43