Differences Between Mathematica's Command Line and Notebook Frontend

There are many differences in behavior between Wolfram Mathematica's command line interface and notebook frontend, which use different parsers. The differences may be categorized into two groups: those that matter and those that don't. A difference in behavior "doesn't matter" if the behavior is semantically identical, that is, if the different behavior has no effect on Mathematica programs. Semantically meaningful differences are important for programmers to know about and were the primary motivation for this effort to describe Wolfram Language.

The phrase "no effect" needs qualification, because Mathematica is able to inspect its own behavior. In this context, no effect means the difference can only be detected using homoiconic reflection, e.g. inspecting the literal text of code or inspecting some undocumented internal structure of the system. However, see the section Hashing below.

Semantically meaningful differences

Semantically meaningful differences can effect how programs are executed. The first item in this section, Hashing, shows that all syntactic differences are semantically meaningful. Despite this fact, we nonetheless place syntactic differences that only effect hashing under the "semantically equivalent" category.


From Hash—Wolfram Language Documentation

  • The "Expression" hash code is computed from the internal representation of an expression and may vary between computer systems and from one version of the Wolfram Language to another.
  • For hash code types (such as "SHA") that operate on sequences of bytes, Hash[expr, \[Ellipsis]] first converts expr to bytes according to ... bytes based on ToString[FullForm[expr]].

As a consequence of the above, any expression for which the FE and command line give different FullForm expressions also have different hashes in each. Many examples of this are given below.

Determining the FullForm expression of an expression

Different methods of determining FullForm give different answers. The following two ways to transform an expression to FullForm give different results such that only one of them is an error.

In[1]:= ToExpression["Hold[a;;\[Intersection]b\[SquareIntersection];;c]"]//FullForm
Out[1]//FullForm= Hold[Span[SquareIntersection[Intersection[Span[a,All],b],System`Private`DummyId],c]]
In[3]:= ToExpression["a;;\[Intersection]b\[SquareIntersection];;c",StandardForm,Hold]//FullForm
During evaluation of In[3]:= Syntax::sntxf: "a;;\[Intersection]b\[SquareIntersection]" cannot be followed by ";;c".
During evaluation of In[3]:=
   Invalid syntax in or before 

Out[3]//FullForm= $Failed

If the expressions within the strings are entered as expressions in the FE, it is a syntax error. However, only the second form of ToExpression gives a syntax error in the command line as well.

Number forms

These number forms should be accepted but fail differently in the FE vs. CL.

2``\:22127 (* Differs in command line vs FE vs `ToExpression`. *)
(* 2 *)
(* Syntax::snthex: 4 hexadecimal digits are required after \: to construct a 16-bit character. *)
(* Syntax::tsntxi: "2.\[Minus]7" is incomplete; more input is needed. *)

Accuracy[2``\:22127] (* Same as above. Fails in both FE and CL the same, `ToExpression` different. *)
(* ToExpression::sntx: 
   Invalid syntax in or before "Accuracy[2``\[Minus]7]".
(* Syntax::sntxf: "Accuracy" cannot be followed by "[2``\:22127]". *)

2``\[Minus]7 (* WARNING: Crashes command line interface leaving zombie kernel running at 100% of CPU. *)
(* Syntax::tsntxi: "2.\[Minus]7" is incomplete; more input is needed. *)

Number forms that are malformed but fail differently. This difference in error message is common not just in number forms, but these supply convenient examples.

(* Syntax::sntxf: "3" cannot be followed by "``+". *)
(* Syntax::tsntxi: "3.+" is incomplete; more input is needed. *)

(* Syntax::sntxf: "3" cannot be followed by "``-". *)
(* Syntax::tsntxi: "3.-" is incomplete; more input is needed. *)

(* Syntax::tsntxi: "2.78`26``10" is incomplete; more input is needed. *)
(* Syntax::sntxf: "2.78`26" cannot be followed by "``10". *)

(* Syntax::tsntxi: "2.78`26`10" is incomplete; more input is needed. *)
(* Syntax::sntxf: "2.78``26" cannot be followed by "`10". *)

Number forms whose interpretation is debatable but which fail differently:

3``\[Infinity] (* WARNING: Crashes command line interface leaving zombie kernel running at 100% of CPU. *)
(* $CharacterEncoding::utf8: The byte sequence {249} could not be interpreted as a character in the UTF-8 character encoding. *)

1.0*^1.9 (* Parsed by FE as (1.0*^1)*0.9. *)
(* General::ifexp: The exponent 1.9 is not an integer.
Syntax::sntxb: Expression cannot begin with "1.0*^1.9". *)
(* 9. *)

Parsing identifiers in input

Consider the following command line session:

In[1]:= a\[RawEscape] = 7                                                       
Out[1]= 7

In[2]:= a\[RawEscape]^2                                                         
Out[2]= 49

It is impossible to do the same in the FE, as the FE insists on separating the a and \[RawEscape] and then doesn't know what to do with the input. Copy+pasting as plain text, as I have done below, automatically inserts a space between the a and \[RawEscape].

In[1]:= a \[RawEscape]=7
During evaluation of In[5]:= Set::write: Tag Times in \[RawEscape] a is Protected.
Out[1]= 7
In[2]:= a \[RawEscape]^2
Out[2]= \[RawEscape]^2 a

To see what the FE is doing, compare

In[1]:= MathLink`CallFrontEnd[ FrontEnd`UndocumentedTestFEParserPacket["a\[RawEscape]a", False]]
Out[1]= List[BoxData[RowBox[List["a","\[RawEscape]a"]]],StandardForm]
In[2]:= MathLink`CallFrontEnd[ FrontEnd`UndocumentedTestFEParserPacket["a\[Alpha]a", False]]
Out[2]= List[BoxData["a\[Alpha]a"],StandardForm]

You can, however, begin an identifier with \[RawEscape] in the FE:

In[1]:= \[RawEscape]a = 7                                                       
Out[1]= 7

In[2]:= \[RawEscape]a^2                                                         
Out[2]= 49

A similar but distinct phenomenon happens with \[LongDash]. The difference is, the FE treats a\[LongDash]b as three symbols multiplied together, whereas it interprets a\[RawEscape]b as Times[a,\[RawEscape]b].

In[1]:= Hold[a\[LongDash]b]//FullForm
Out[1]//FullForm= Hold[Times[a,\[LongDash],b]]
In[2]:= ToHeldExpression["a\[LongDash]b"]//FullForm
Out[2]//FullForm= Hold[a\[LongDash]b]


"What is a valid identifier in Mathematica?" is currently an open question. All known methods of determining this, including SymbolNameQ and UnicodeCharacters.tr, do not provide correct answers.

Parsing expressions involving ;;

ToDo: Is this caused by differences in precedence or by incorrect input parsing?

In[15]:= FullForm[a;;\[Intersection]a\[SquareIntersection];;a]
Syntax::sntxf: "a;;\[Intersection]a\[SquareIntersection]" cannot be followed by ";;a".

In[13]:= ToExpression["a;;\[Intersection]a\[SquareIntersection];;a", StandardForm, Hold]//FullForm
Out[13]//FullForm= Hold[SquareIntersection[Intersection[Span[a,All],a],Span[1,a]]]

In[15]:= FullForm[a;;\[Intersection]b]
Syntax::sntxf: "a;;" cannot be followed by "\[Intersection]b".

In[14]:= ToExpression["a;;\[Intersection]b", StandardForm, Hold]//FullForm
Out[14]//FullForm= Hold[Intersection[Span[a,All],b]]

Expressions involving .

(* Times[Repeated[Unset[b]], 1] *)
(* Syntax::sntxf: "b=" cannot be followed by "...1". *)

The operators (each written as an example here) that DO NOT steal the . from a trailing digit are a/.1, a/:b=.1, and a=.1. As noted, //. is inconsistent with /., and the Dot operator (a.b) needs to be treated as a special case. This places the “precedence” of a leading decimal point between //. and /., which is consistent with everything except the Dot operator.

Obscure grouping symbols

The obscure grouping symbols in UnicodeCharacters.tr are sometimes treated as parentheses, sometimes as symbols, but don’t go away in the output. Other times they aren't parsed at all.

4*3+2 (* Cannot be copy+pasted into my terminal without special chars disappearing. *)
(* 14 *)
(* 20 〔 〕*)

4*\:3014 3+2 \:3015                                                     
(* 20 〔 〕 *)
(* 12 〔 + 2 *)

FullForm[Hold[4*\:3014 3+2 \:3015 ]  (* Note the inconsistency of the CL, which cannot parse this.. *)                 
(* Hold[Times[4,Times[\:3014,Plus[3,2],\:3015]]] *)
(* Syntax::sntxi: Incomplete expression; more input is needed . *)

ToExpression["4*〔3+2〕"]//FullForm  (* Can you spot where the `3` goes? *)
(* Plus[Times[2,\:3015],Times[4,\:30143]] *)

ToExpression["4*〔3+2〕"] (* This is where the 3 goes: The `〔3` is treated as an identifier.  *)
(* ) 2 〕+4 〔3 *)

Differences that are semantically equivalent

Flattening Times in arithmetic expressions with exact numbers

Command line Mathematica and Notebook Mathematica produce different output for FullForm[Hold[-+x 2]]:

(Notebook) In[1]:= FullForm[Hold[-+x 2]]
(Notebook) Out[1]//FullForm= Hold[Times[Times[-1,Plus[x]],2]]

(Terminal) In[1]:= FullForm[Hold[-+x 2]]
(Terminal) Out[1]//FullForm= Hold[Times[-1, Plus[x], 2]]

(Definition) In[1]:= FullForm[Hold[-+x 2]]
(Definition) Out[1]//FullForm= Hold[Times[Minus[Plus[x]], 2]]

Looks like the notebook doesn't properly flatten Times[]. Compare this to +-x 2 for which both the notebook and the command line give the same result:

    In[1]:= FullForm[Hold[+-x 2]]
    Out[1]//FullForm= Hold[Times[Plus[Times[-1, x]], 2]]

Note that I could have just as easily used -+2x instead but wanted to avoid confusion with the following oddity, which is distinct: Mathematica does not parse subtraction as-is.

In[1]:= FullForm[Hold[x - 4]]
Out[1]= Hold[Plus[x,-4]]

In[2]:= FullForm[Hold[x-y]]
Out[2]= Hold[Plus[x, Times[-1, y]]]

Mathematica's behavior is not entirely consistent when it comes to subtracting a constant. Mathematica interprets x-4 as Plus[x,-4], but if the constant is already negative, Mathematica doesn't simplify the multiplication by -1:

In[1]:= FullForm[Hold[x - -4]]
Out[1]= Hold[Plus[x,Times[-1, -4]]]


These aren't differences between interfaces. They're just bugs.

This is interpreted incorrectly:

16^^9fe.c3`\[Minus]7 (* Treated as subtraction. Note: Cannot be copy+pasted into FE. *)
(* 2551.76 *)

This is fixed in version 12:


Crash the front end:


(See the sections on number forms above for more ways to crash Mathematica.)

Other Homeless Quirks

The expression lhs/.1->2 is division by 0.1, but lhs /. 1 -> 2 is ReplaceAll. It contradicts two other similar forms. Compare

ToHeldExpression["1/.1"]//FullForm --> Hold[Times[1,Power[0.1`,-1]]]
ToHeldExpression["1//.1"]//FullForm  --> Hold[ReplaceRepeated[1,1]]
ToHeldExpression["1...1"]//FullForm  --> Hold[Times[RepeatedNull[1],1]]

Operators greedily consume tokens - except in the case of /..