views:

84

answers:

2

I am presently learning Lexical Analysis in Compiler Design. In order to learn how really a lexical analyzer works I am trying to build one myself. I am planning to build it in Java.

The input to the lexical analyzer is a .tex file which is of the following format.

\begin{document}

    \chapter{Introduction}

    \section{Scope}

    Arbitrary text.

    \section{Relevance}

    Arbitrary text.

    \subsection{Advantages}

    Arbitrary text.

    \subsubsection{In Real life}

    \subsection{Disadvantages}

    \end{document}

The output of the lexer should be a table of contents possibly with page numbers in another file.

1. Introduction   1
  1.1 Scope         1 
  1.2 Relevance     2  
    1.2.1 Advantages  2
       1.2.1.1 In Real Life  2
     1.2.2 Disadvantages   3 

I hope that this problem is within the scope of the lexical analysis.

My lexer would read the .tex file and check for '\' and on finding continues reading to check whether it is indeed one of the sectioning commands. A flag variable is set to indicate the type of sectioning. The word in curly braces following the sectioning command is read and written along prefixed with a number (like 1.2.1) depending upon the type and depth.

I hope the above approach would work for building the lexer. How do I go about in adding page numbers to the table of contents if that's possible within the scope of the lexer?

+2  A: 

You really could add them any way you want. I would recommend storing the contents of your .tex file in your own tree-like or map-like structure, then read in your page numbers file, and apply them appropriately.

A more archaic option would be to write a second parser that parses the output of your first parser and the line numbers file and appends them appropriately.

It really is up to you. Since this is a learning exercise, try to build as if someone else were to use it. How user-friendly is it? Making something only you can use is still good for concept learning, but could lead to messy practices if you ever use it in the real world!

glowcoder
I didn't quite get your first point of storing the contents in tree-like structure. Would you mind elaborating on this? I wish to do the entire process of building the table of contents in the scope of lexical analysis and not use a parser. I'm thinking of implementing a lesser user-friendly approach in which user has to insert '\pagebreak' at the end of every page.
primalpop
The syntax of `\pagebreak` isn't un-friendly at all - it seems quite reasonable to me. Also, in this case there is little difference between your lexer and your parser. Your lexer simply generates tokens - in order to do something with those tokens you `need` a parser. If you combine them into a single entity, that's fine although it may limit you down the road. As to the storage, consider a scenario with an object TOCEntry with `String loc; String desc; int pagenum;` You create a tree or map of TOCEntry for example `entries.add(new TOCEntry("1.2","Relavence"));` (comment continued on next)
glowcoder
where, obviously, "1.2" and "relavence" are generated from your input and not hardcoded... Then once you read in your page numbers file, if you had "1.2" page 2, you could then (if you used a Map with key of loc, go `entries.get("1.2").setPageNum(2);` Obviously these are contrived, hardcoded examples, the inputs of which would be dynamic by reading in the file.
glowcoder
A: 

What you describe is really a lexer plus parser. The job of the lexical analyser here is to return tokens and ignore whitespace. The tokens here are the various keywords introduced by '\', string literals inside '{', '}' and arbitrary text elsewhere. Everything else you dscribed is parsing and tree-building.

EJP