18

Even further, I would be happy to see a definition of the tikz language in the usual manner programming languages such as Java and Pascal are defined.

The reason I ask is that I keep getting mysterious error messages for the tiniest typos. Essentially, incorrect use of the underlying languages leads to a "crash" of the compiler. This crash sometimes gives useful error messages, but sometimes they are hard to decipher.

Yossi Gil
  • 15,951
  • 1
    This is an interesting issue. TeX itself cannot be defined with a BNF as it can modify its own grammar at runtime. But the TikZ high level language may be a definable subset, if we suppose no TeX wizardry is involved. Possibly the definition will contain some <arbitrary TeX code here> stuff though. – marczellm Jan 13 '14 at 22:21
  • This IDE uses a small subset of tikz which has a CFG: http://tikzit.sourceforge.net/manual.html – Yossi Gil Jan 13 '14 at 23:02
  • 2
    though I don't understand the question the errors are due to TeX that often come out cryptic and that has been discussed many many times on the site. – percusse Jan 14 '14 at 06:36
  • I agree. The "fault" lies with TeX not with tikz. The idea, proposed as question is to have a "tikz" pre-processor, which will "compile" tikz code into tikz code. On course, it would produce useful error messages. However, it would make sure that the output it generates will compile correctly with the "real" tikz. – Yossi Gil Jan 14 '14 at 06:39
  • What is the relationship between CFG (in the question) and BNF (in @marczellm's comment)? – cfr Mar 27 '15 at 16:58
  • @cfr: BNF is a notation used to define CFGs. It likely has a nice Wikipedia article. – Mark Mar 27 '15 at 18:02

1 Answers1

8

To give a non-CS answer: Not without a yet another complete frontend that implements a repair of the syntax.

The actual mechanism of TikZ is essentially \pgfutil@ifnextchar which is roughly: check the next line and decide what to do.

A nice example of this is

\def\tikz@lineto{%
  \pgfutil@ifnextchar |%
  {\expandafter\tikz@hv@lineto\pgfutil@gobble}%
  {\expandafter\pgfutil@ifnextchar\tikz@activebar{\expandafter\tikz@hv@lineto\pgfutil@gobble}%
    {\expandafter\tikz@lineto@mid\pgfutil@gobble}}}
\def\tikz@lineto@mid{%
  \pgfutil@ifnextchar n{\tikz@collect@label@onpath\tikz@lineto@mid}%
  {%
    \pgfutil@ifnextchar c{\tikz@close}{%
      \pgfutil@ifnextchar p{\tikz@lineto@plot@or@pic}{\tikz@scan@one@point{\tikz@@lineto}}}}}
\def\tikz@lineto@plot@or@pic p{%
  \pgfutil@ifnextchar i{\tikz@collect@pic@onpath\tikz@lineto@mid p}{%
    \pgfsetlinetofirstplotpoint\tikz@plot}%
}

Now let's pick c as the next argument. We can see that it goes in and out of if cases, discards nope it is not a |, then it must be -. So it runs out of possiblities and assumes. Now once we see this, we can start screwing around with it

\begin{tikzpicture}
\draw (0,0) -x (1,1);
\draw (0,0) -! (1,1);
\draw (0,0) -@ (1,1);
\end{tikzpicture}

and yes they all work. The reason, I believe, for this flexibility is not any context free grammar but leaving open hooks for future implementations. There are more of these slots; for example the hobby library hacks into controls keyword very nicely.

Ok, suppose it was indeed -- in the previous step and the next char is c. Now we are parsing again. We check if something starts with n, nope, then a c.

\def\tikz@close c{%
  \pgfutil@ifnextchar o{\tikz@collect@coordinate@onpath\tikz@lineto@mid c}% oops, a coordinate
  {\tikz@@close c}}%

As you can see from the comment, it hopes to find cycle or coordinate. If it was indeed a coordinate, it would have to pass this TeX obstacle

\def\tikz@collect@coordinate@onpath@#1oordinate{%
  \pgfutil@ifnextchar[{\tikz@@collect@coordinate@opt#1}{\tikz@@collect@coordinate@opt#1[]}}%}

If you have a typo on coordinate, say,

\begin{tikzpicture}
\draw (0,0) -x (1,1) cordinate (a);
\end{tikzpicture}

You get the error Use of \tikz@cosine doesn't match its definition which is a TeX error that TikZ have no authority over. And also the error is indeed super cryptic, are you kidding me who asked for cosine anyway? 1

So my argument is about the success of TikZ to trick us to think that the tediousness of TeX with macros and so on is disappeared and TikZ is more forgiving. It is quite not the case. The biggest problem that TikZ has is that there is no safe option to fall back to. At any point of the parsing mechanism only the correct branch leads to a meaningful string of PGF syntax and that is a very strict specification. So I wouldn't bet my money on the possibleness but you never know. There are a lot of clever people out there.

1 (by the way this is another switch that I skipped that checks the letter after co and assumes cosine if can't branch off)

Flow
  • 1,013
percusse
  • 157,807