A project progress report submitted for the award of
B.Sc. Computer Science

First Project Supervisor:	Ed Zaluska
Second Project Supervisor:	Gwil Edmonds

JavaScript Parser & Error Reporter
By Alex Walker
24th January, 1998

In the Internet and Intranet Development industry, the scripting language JavaScript is used within an HTML document to control and interact with the web browser, and provide dynamic content. On the server, it is used to format pages on the fly, often including data from a database.

A regularly occurring problem is that JavaScript is interpreted at runtime by the web browser, not compiled in advance. This results in errors occurring at runtime. This may produce an error dialog box, or more often than not, the error will not be reported, and the script will not function correctly. This makes it hard to identify errors in the script, and hard to debug these errors.

The end result of this project will be a parser and error-checking program that will load a JavaScript file, and identify syntactical and grammatical errors within that script. It will also report on portability issues between browsers and common programming errors.

Table of Contents

1	Enhanced Project Description
1.1	Project Scope
1.1.1	Programming Language Choice
1.1.2	User Interface
1.2	Project Schedule
2	Proposed Final System Design
2.1	System Design Summary
2.2	System Modules
2.3	Object Diagram
3	Justification of Approach
4	Account of Work to Date
4.1	Work to Date
4.2	Summary of Work to Date
5	Estimate of Further Work and Support Required
5.1	Further Work
5.2	Anticipated Support Required
6	References

1. Enhanced Project Description

1.1 Project Scope

1.1.1 Programming Language Choice

Whilst investigating the possibility further, it became clear that writing a fully function lexer and parser in Java was indeed a project in itself, let alone then developing it for use with the JavaScript Language. I decided then, than rather than continue down this course, I would code the project using ANSI C and the Lex and Yacc tools. This would make the finished product more maintainable, which is one of the goals of the project. And whilst the resultant code is ANSI C, this can still be compiled for any platform, due to the C language being high level in nature.

1.1.2 User Interface

1.2 Project Schedule

Figure 1-1

Figure 1-2

There are in fact few changes. I have spent more time reading than I had originally intended, which is not a bad thing. My design stage has been as expected. I also started coding earlier than anticipated. I originally wanted to get stuck in with the design before starting any coding, but the design itself benefited from some experimentation with Lex and Yacc.

2. Proposed Final System Design

2.1 System Design Summary

The finished project will consist if compiled binaries for the relevant platform (DOS, Win32, UNIX etc). This program will load in a JavaScript source file and will report on syntax and semantic errors if any exist. The program will be run from the command line, and have some command line options, such as re-direction of the output. The program will be written using the Lex and Yacc compiler tools. These in turn will generate ANSI C source code. This can then be compiled for the appropriate target platform.

2.2 System Modules

1. Lexer - Breaks down incoming lines of code into tokens. These are passed to the parser.
2. Parser - Recognizes sentences of correct grammar in the token streams.
3. Source Store - Stores lines of original source code, and uses them when reporting errors.
4. Error Generator - Called by lexer or parser to generate error messages. Uses Source Store to reproduce the original code.

2.3 Object Diagram

Figure 2.1 - System object diagram

3. Justification of Approach

4. Account of Work to Date

4.1 Work to Date

Table 1 - Account of Work.

Week 1:	Decided upon a project title, goals and scope.
Week 2:	Agreed Project Brief completed. Time schedule decided. Started to read "Introduction to Compiler Techniques" by J. P. Bennet.
Week 3:	JavaScript BNF found on the Internet. Preparing home machine for project writing.
Week 4:	Investigated using GMD Compiler tools, as suggested by Denis Nicole.
Week 5:	Met with Second Supervisor to discuss project. Reading "Lex and Yacc" by ORA. Installed GMD Compiler tools. Decided learning curve was too high for this project.
Week 6:	Requirements document written explaining in more detail goals of the project.
Week 7:	Writing first version of the Lexer.
Week 8:	Types and Reserved words of the JavaScript language identified. First version of Lexer complete.
Week 9:	Lexer refined, and test harness is written and working.
Week 10:	All punctuators of the JavaScript language identified and included.
Week 11:	Investigating design of the symbol table and Lex/Yacc interface.

4.2 Summary of Work to Date

5. Estimate of Further Work and Support Required

5.1 Further Work

1. Get a simple parser working, interfacing with the lexer, and using a simple test harness.
2. The parser should then be extended to sensibly handle correct grammar.
3. Some thought needs to be given to testing of the working code. A test script should be produced for the finished product.
4. The error generator should be designed and implemented. Source code should be captured and used in reporting errors.

5.2 Anticipated Support Required

Machine Name	'Dodger' - after Roger the Dodger from the Beano comic.
Processor	Intel 486DX4 100MHz
RAM	16MB
Hard Disk	500MB
Operating System	Red Hat Linux 4.2 (Kernel 2.0.30)
Miscellaneous	The machine is networked to allow ease of development and backup

There are many advantages of using a separate machine for this work. Mostly, that it is less likely to be "interfered with" by other people and programs.

6. References

1. John R. Levine, Tony Mason & Doug Brown, Lex and Yacc, O'Reilly & Associates, Inc.
2. J. P. Bennet, Introduction to Compiling Techniques, McGraw-Hill International