Revision as of 11:00, 28 September 2010

Project (Programming Language Parser)

Description

My project is a parser for LTF (Logic, Types, Flow). The scope is limited to the parser only due to amount of work associated with writing a full compiler or interpreter, and the parser will sufficiently show/prove the design in implementation. I have a previous parser (written in C++) that can parse a language with similar logic/type declarations. However this project is mostly new, some parsing, OO, and language concepts are shared from the previous project.

Goals/Requirements

• Parse and create an AST (Abstract Syntax Tree) of the LTF.

About LTF

LTF is designed for writing code similar to the way the shell works, except with much more flexibility, as data can be pushed to any of the objects, not just in a forwards directions. Code is written in 3 seperate parts:

• Type information is the meta data describing each of the types in the system. (Like a header file)
• Logic is the code that implements the functionality of the types. (like normal code files)
• Flow creates objects and connects them together (similar to a main function)

Things to note:

• LTF supports single inherientance.
• LTF supports interfaces, on a per function basis.
• LTF is a push system, data always moves from in to out.
• input functions do not return a value, the correct solution is to input an error to the caller.
• Logic is pre-order, and bracketing is non-optional.

Design

Root types:

• Module (all of [name].{type,logic})
• Program (a program, described by a flow)
• AST (some item in the AST, an option of some sort)
• Connection (some item of flow)

Types inherieting from AST:

• CodeAST
• AccessorAST

Design Justification

• Code parsing has an inherent requirement for a Switch statement smell. I have placed all of the switch statements in the parsers. This prevents the need for switch statements in classes, or any later part of the processing.
• Overriding the code generation in each submodule, and having a single function definition that generates the code helps to Avoid downcasting.
• In the parsing the code Avoid side effects gives the global module a nextToken() and currToken() function, because most of the time the current token is required again, and storing it as a local variable would not work.
• Big design up front is used to for this project, because the language as a whole needs to be designed before a parser can started.