I type some equations from text books into database, which later read from Mathematica to solve.

Since I do this manually, sometimes I make mistakes where I type Exp(2*x) instead of Exp[2*x] or type Sin(2*x) instead of Sin[2*x] and so on.

The problem is that when reading this code into Mathematica, no error is generated.

When writing this into the frontend, a RED syntax coloring alerts one that input is not valid. But I am not doing this via the front end, so I do not see the RED syntax.

Is there an option in Mathematica to cause Mathematica when processing the input, to generate an error for any input which also causes the RED syntax warning to show at input?

Here is an example


No error is generated

Mathematica graphics

I'd like to set an option where DSolve in this case generate an error and not silently treat Exp(2*x) as 2*Exp*x

Mathematica graphics

This way when I run my script, it will generate an error on this input, so I can go fix the input.

I use plain text editor to enter these equations into the database (SQL) and the editor I am using has no syntax error highlting for Mathematica mode. I use notepad++. Even if I find an editor which can highlight this, it will not help me, since the input is SQL input and not Mathematica input and these equations are actually strings in the file I am using as input to the database. Later when I read them into Mathematica, I convert them to expressions.

So the best solution is for Mathematica/DSolve to generate an error and not silently process this input.

Is there such a setting? something like strict mode parsing or such?

If not, is there a builtin function which can detect if an expression would generate RED syntax highlighting in front end? If so, I can call this function for each input to validate it. something like


Which will return True because the front end has Red syntax on it.

V 14 on windows.

  • $\begingroup$ Perhaps some of those issues related to the round brackets might be mitigated by using the TraditionalForm as a second parameter for ToExpression. For the example above ToExpression["Exp(2*x)", TraditionalForm] and ToExpression["Exp[2*x]", TraditionalForm] both give E^(2 x) $\endgroup$
    – vindobona
    Commented Mar 9 at 23:44

2 Answers 2


Using the code inspector can show you issues with the code,

<< CodeInspector`

enter image description here

This can bring up possible issues for you to investigate. To analyze a whole file use CodeInspect[File[...]]

This does not query the front end, so it will bring up different issues from the syntax highlighting.

  • $\begingroup$ To add to that last point, the FE syntax highlighting is likely less reliable than the kernel-level analysis too in general. I've gotten lots of red highlighting for totally normal code in the past $\endgroup$
    – b3m2a1
    Commented Mar 9 at 23:30
  • $\begingroup$ I see. If the result is empty then there is no issue! so all I have to do is check length of result. !Mathematica graphics $\endgroup$
    – Nasser
    Commented Mar 10 at 0:33
  • $\begingroup$ However, it fails on this "y''[x]+y[x]==Exp{2*x}" in this case it returns EMPTY result, which means the code has no issue,. But front end shows RED. Here is screen shot !Mathematica graphics Should not CodeInspect have returned issue with this input? $\endgroup$
    – Nasser
    Commented Mar 10 at 0:35
  • $\begingroup$ @b3m2a1 What about the example I showed above? "y''[x]+y[x]==Exp{2*x}" where code inspector says there is no issue, but front end correctly shows RED syntax on it? $\endgroup$
    – Nasser
    Commented Mar 10 at 0:45

This is an extended comment related to detecting Exp{2x} issues.

Looking at CodeInspector`AggregateRules`Private`scanImplicitTimesDispatch, it seems that CodeInspector only recognizes issues of type Exp(2x). However, you can simply write an additional checker by first using CodeParser`CodeConcreteParse to parse the code, then manually matching the problematic part of the code.

scanImplicitTimesCurlyBracket[code_String] := !FreeQ[CodeParser`CodeConcreteParse[code], 
   CodeParser`InfixNode[Times, {CodeParser`LeafNode[Symbol, _, _], 
     CodeParser`LeafNode[Token`Fake`ImplicitTimes, _, _], 
     CodeParser`GroupNode[List, _, _]}, _], All]

(* False *)
(* True *)

However, this will also detect a problem for something like a{2x} (which you might find problematic), the same way CodeInspect would warn you for a(2x). You could avoid this by putting some constraint on the preceding symbol, for example checking that it is a NumericFunction (or you could check that it is a capitalized symbol or that it is part of the System context ...):

scanImplicitTimesCurlyBracket2[code_String] := !FreeQ[CodeParser`CodeConcreteParse[code], 
   CodeParser`InfixNode[Times, {CodeParser`LeafNode[_, (sym_ /; 
        MemberQ[Quiet@Attributes[sym], NumericFunction]), _], 
     CodeParser`LeafNode[Token`Fake`ImplicitTimes, _, _], 
     CodeParser`GroupNode[List, _, _]}, _], All]
(* False *)
(* True *)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.