Your task is to develop a Lexer (aka Scanner) for the programming language whose lexical structure is described in this document:
This document is shared with UF affiliates only, so you will need to log into google with your Gatorlink ID. Please do NOT send requests for permission for access from another google account.
Interface for the Lexer itself, your lexer class should implement this interface
Interface for the Tokens, your token class should implement this interface. Also, the enum Kind, which distinguishes the different tokens is defined in this interface. When determining the position of a token in the input source code, start counting both lines and columns at 1.
Factory class to provide instantiations of your lexer. You will need to modify a line or two in this class.
The superclass of all the Exceptions that we will throw in the compiler
The Exception that should be thrown for all errors in the input that are discovered during lexing.
Example Junit tests. This class will be expanded with additional tests and used for grading so it is essential that your code runs with this code and passes these tests. The examples also demonstrate how to write tests, including tests where an exception is expected. You may (and should!) add additional tests to this class; your version will not be graded.
- A class (or classes) that implements the IToken interface and represents tokens.
- A class that implements the ILexer interface and tokenizes its input according to the given lexical structure.
- repeatedly invoking next() should return all of the tokens in order. After all the tokens have been returned, subsequent calls should return a token with kind EOF.
- If an error is discovered, throw a LexicalException. The error message will not be graded but you will appreciate it later if your error messages are informative.
- You may implement your lexer so that it generates tokens on demand, or you may compute all the tokens first and then return them when requested. If you choose the latter approach, make sure that no exceptions are thrown until the error occurs. (For example, if the input is “123 @”, the first call to next should return a NUM_LIT token with 123. The second call should throw an exception.) The ERROR kind may be useful for managing exceptions, it is not required to be used and no ITokens with kind ERROR should ever be returned from next() or peek().
- Modify CompilerComponentFactory.java so that its getLexer method returns an instance of your ILexer implementing class.
All of your classes for this project should be in package edu.ufl.cise.plpfa22;
Do not modify the provided code except CompilerComponentFactory.java and LexerTests.java.
A jar file with containing the Java sources of all the code (including provided code) needed to test your lexer implementation. (Do not include .class files). Name your jar file Lastname0_Lastname1_HW1.jar (or Lastname_HW1.jar if your group only has one member). Note that some IDEs default to including class files, so double check that your jar file contains the source files only.
A zip file containing your git repository WITH its history. The contents will not be graded, but failure to turn it in may result in a zero on the assignment. It may be used in cases of academic dishonesty, to determine contributions of team members, and to evaluate software engineering practices. To obtain this file, go to the parent of your local git repository and create a zip file. Your git repository should contain a (hidden) directory called .git (dot git). Do NOT use the “download zip file” option on github-it does not include the history.
- Study the lexical structure and determine its DFA. Systematically implement the DFA as discussed in class.
- Work incrementally, testing as you go.
- Avoid static variables as they do not always behave as expected during unit testing.
- You may use Integer.parseInt to convert a string to an int value. If a NumberFormatException is thrown, this should be caught and converted to a LexicalException.
- Before turning in:
- Remove debug printing
- Check for and remove extraneous import statements. Unless otherwise specifically indicated, only classes from the standard java distribution should be used. Nonstandard import statements may cause your code to fail to compile on our system, which would result in a zero on the project.
- Double check that you have complied with the instructions above.