Mathematica Stack Exchange is a question and answer site for users of Mathematica. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


Usually, I give detailed descriptions when I have a question which sometimes lead to that users don't write their answers because they maybe think their answer is too simple. Therefore, I chose to just throw the direct question in the room and collect the ideas of all answers.

Although it seems, that we cannot get a simple tokenizer by using functions like TreeForm, MakeBoxes, MakeExpression, ... I want to give some background information now:

What really bothers me is, that we have here on Mathematica.SE a highlighter for Mathematica code which is far away from perfect, but which does a reasonable job. If I want to include a snippet of code into a LaTeX document on the other hand, I'm totally stuck with a b/w-pdf export from Mathematica or with the Mathematica 5.2 support of the listings package.

Therefore, I hacked a simple parser of the html-output of our google-prettify plugin. This seems to work reasonable and with a little bit adjustment, one could include styled Mathematica-code into a LaTeX document. It should be noted, that I don't intent to export formulas or sophisticated styled code. I want to stick with good old ascii-style code which is used in most packages.

Before I used the html-output I was again having a long look at Leonids formatter but at its current state it lacks of the same issues since it relies on MakeBoxes as well and there are other issues. Leonid pointed out, that he want to reimplement this completely.

On the other hand, we have functions like SyntaxLength, SyntaxQ, MakeExpression, MakeBoxes (and their To counterparts), all kind of Forms, we can keep expressions unevaluated and so on. Therefore, I was asking myself whether we can do the tokenizing much easier with Mathematica that it is possible with the JavaScript from google-prettify.


Is it possible to implement a reliable tokenizer which takes a valid input-string of Mathematica code and returns a list of tokens without implementing the rules of the Mathematica-language itself?

Although tokens usually don't contain whitespace characters, for the purpose of testing it would be nice, if all characters stay even in the tokenized version.

Especially I want

input == StringJoin@@Tokenize[input]

to return True.

Take for instance this function

Tokenize[str_String /; SyntaxQ[str]] := 
  With[{expr = MakeExpression[str, StandardForm]},
   Most[Drop[Flatten[MakeBoxes[expr] /. {
        RowBox -> List, SuperscriptBox[a_, b_] :> {a, "^", b}, 
        "\[Rule]" :> "->"}], 2]]

 {"Plot3D", "[", "{", "x", "^", "2", "+", "y", "^", "2", ",", 
 "-", "x", "^", "2", "-", "y", "^", "2", "}", ",", "{", "x", 
 ",", "-", "2", ",", "2", "}", ",", "{", "y", ",", "-", "2", 
 ",", "2", "}", ",", "RegionFunction", "->", 
 "Function", "[", "{", "x", ",", "y", ",", "z", "}", ",", "x", 
 "^", "2", "+", "y", "^", "2", "<=", "4", "]", "]"}

Although the output looks good here, inside Mathematica we have \[LessEqual] instead of <= (due to the StandardForm I assume). Furthermore, all different kind boxes need to be handled and I'm afraid many more things.

Is there any chance to get this working really correctly?

Test examples:

In some of these cases I'm not sure whether my given output is the correct one. E.g. the handling of linebreaks may be system-dependent, a_ seems to stay together in the box-representation (which would be ok), ...

"a\nb" (* {"a","\n","b"} *)
"a_:>a/2<=3" (* {"a_",":>","a","/","2","<=","3"} *)
"1`3+1.00`3" (* I'm not sure how this should be tokenized but my intention should be clear *)
share|improve this question
What can you say about the input? What if it has string representation of boxes, how would you want the output? – Rojo Oct 16 '12 at 1:37
@Rojo I updated my question with additional information. You can assume that the code I want to tokenize is simple ascii-code like it is used on our site here. – halirutan Oct 17 '12 at 1:19
up vote 10 down vote accepted
tokenize[str_] := Module[{exp,
   nb = CreateDocument[{ExpressionCell@
       InputForm@MakeExpression[str, StandardForm]}, 
     Visible -> False]},
  SelectionMove[nb, Next, Cell];
  exp = Flatten[
    NotebookRead[nb][[1, 1]] /. {RowBox -> List, 
      i_String /; StringMatchQ[i, Whitespace ..] :> Sequence[]}];
  exp[[3 ;;-2]]

Haven't tested this much. Does this give the output you expect?




Thanks to @JohnFultz's recent introduction of the following front end undocumented function, this becomes straightforward

   FrontEnd`UndocumentedTestFEParserPacket[t, False]], _String, Infinity]
share|improve this answer
The idea is good! Don't remove whitespace, because I want input == StringJoin@@tokenize[input] to return true; see my update. Your function adds a ] to the tokens at the end: tokenize["a+b"] – halirutan Oct 15 '12 at 22:17
@halirutan, with this approach you could only make input==StringJoin... if you can offer certain guarantees on the input's format. Otherwise, a manual approach, working on the strings, splitting them, is probably the only way I guess. Fixed the extra "]", thanks – Rojo Oct 15 '12 at 22:33
aah! You beat me to stealing the Futz! – R. M. Oct 21 '12 at 0:09
@Rojo, Shame on you both. You could have at least noticed, that his name is Fultz when you are stealing his code ;-) – halirutan Oct 21 '12 at 2:32
Well, if you're going to steal from "the Futz" (my new nickname?), you could at least tighten up the code. Instead of the DeleteCases you have, how about Cases[#,_String,Infinity]&? And...the question was specified (in boldface, even) as wanting whitespace not to be stripped. In which case the second argument to UndocumentedTestFEParserPacket should be False, not True. – John Fultz Oct 21 '12 at 3:45

This, with a suitable transform function to traverse the tree, would be an adequate tokenizer:

  Plot3D[{x^2 + y^2, -x^2 - y^2}, {x, -2, 2}, {y, -2, 2}, 
   RegionFunction -> Function[{x, y, z}, x^2 + y^2 <= 4]]]]

Mathematica graphics

share|improve this answer
No, I don't think the input can be reconstructed from that. Mathematica did already too much work: compare TreeForm[1`3] and TreeForm[1.00`3]. – halirutan Oct 16 '12 at 0:02
You can of course wrap some Hold around the numeric value, but the outcome stays the same. – halirutan Oct 16 '12 at 0:27
@halirutan Good counter example :) Maybe this case, and perhaps others, needs the application of a pre-processor. If I've used it correctly I don't think tokenize from rojo's solution distinguishes between the two forms you give in your example either. – image_doctor Oct 16 '12 at 7:29
Yes, Rojos tokenize lacks from the same problem. I added more information to my question. – halirutan Oct 17 '12 at 1:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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