User:Scott Parlane/DesignStudy
From CSSEMediaWiki
(Difference between revisions)
Line 1: | Line 1: | ||
− | = Project ( | + | = Project (Programming Language Parser) = |
== Description == | == 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 === | === 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 | |
− | * | + | |
− | * | + |
Revision as of 10:49, 7 August 2010
Contents |
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