| OLD WAY | NEW WAY |
 |
 |
* U.S. Patent # 9,710,243
| OLD WAY | NEW WAY |
|
|
=> Define Syntax
|
A slightly abbreviated side-by-side comparion of a BNF-like grammar and Programmar.
The PERFORM Verb in COBOL |
|
| Old Grammar | New Programmar |
| cPerform := "PERFORM" cParagraph
[("THROUGH" | "THRU") cParagraph] [cPerfTimes]; cPerfTimes := cExpression "TIMES"; cParagraph := cIdentifier; cExpression := cIdentifier | cNumber; cIdentifier := cLetter (cLetter | cDigit | "-")*; cNumber := cDigit cDigit*; cLetter := "A" .. "Z"; cDigit := "0" .. "9"; |
class COBOL_Perform extends COBOL_AbstractStatement {
COBOL_Keyword PERFORM = new COBOL_Keyword("PERFORM"); COBOL_Paragraph startPara; @OPT COBOL_PerformThrough through; @OPT COBOL_PerformTimes times; class COBOL_PerformThrough extends TokenSequence { COBOL_KeywordList THRU = new COBOL_KeywordList("THRU", "THROUGH"); COBOL_Paragraph endPara; } class COBOL_PerformTimes extends TokenSequence { COBOL_Expression number; COBOL_Keyword TIMES = new COBOL_Keyword("TIMES"); } } |
| Scalable: Dependencies are caught automatically. In the Programmar approach, downstream impact of any change will be detected immediately, by the compiler. If somebody were to change the name of an element, all references to that name would be marked as invalid until they were changed accordingly. This allows projects to scale to much more significant levels. It is now conceivable to have dozens of developers working on the same project. |
| Semantics: Entities are not just names. In the AST version, a cParagraph is just an identifier with a name. There is no further information attached to it. If you write a tool to analyze or transform a COBOL program, you will have to search the rest of the AST to find out what is in that other paragraph. With the PST version, the COBOL_Paragraph has a direct reference to that paragraph, including all of its statements, line numbers, references, etc. This greatly simplifies tool-writing. Much of the work in connecting references to definitions can be done as part of the parse process. |
| Modern: Utilize modern programming language methodologies. Because a Programmar is represented in a modern programming language (Java), the methodologies of that language can be used in the Programmar definition. Annotation, for example, is useful for better output formatting, and is also useful for external language documentation. |
| Abstraction: A traditional grammar is typically tailored for just one programming language. With the Programmar parser, the components common to all variations of a particular programming language can be placed into an Abstract Programmar. For example, there are many major variations of languages like Report Program Generator (RPG). The File specification has a similar meaning across each of them, so only minor syntactic variations need to be included in each version of RPG. |
| Inheritance: Frequently, there are variations on a computer programming language. With a traditional grammar, the whole grammar gets copied and edited for each variation. With Programmar Inheritance, only the local changes need to be considered and the rest can be inherited from the main Programmar. |
| Encapsulation: Some computer languages, such as HTML as used for web pages, often include other languages inside of them, such as Javascript or PHP. In a traditional grammar, these are normally combined into a monolithic grammar covering all sub-languages. With Programmar Encapsulation, the main Programmar (e.g., HTML) can simply reference the other Programmar (e.g., Javascript or PHP). |
| Logic: During the parsing process, it is a challenge to mix procedural logic with a grammar that is declarative. With Programmar Logic, the full power of the programming language (Java) is available for complicated cases. Managing the Data Division level numbers in COBOL is a good example where logic is needed to assist the parsing process to build the correct hierarchy. |
| Language | Quirk |
| Python | Indentation is critical |
| COBOL | Picture level numbers are hierarchical |
| Gupta | All spaces are critical |
| HTML | Tables can be nested, and are usually not well-formed |
| PHP | Mix of languages (Perl, HTML, CSS, Javascript) |
| RPG | Three standards: two are fixed columns, one is free format |
| C++ | Macros use a different syntax than regular code |
You can click on variables to see their definitions and references. You can also click on Verbs to see some online documentation.
Sample pretty printing application.
| Grammars and Programmars are rarely perfect. They evolve over time. It is often useful to be able to defer difficult parsing issues, or to skip over particularly difficult lines of source code. |
| Parsing is still considered successful, as long as the rest of the source file has been parsed. I.e., the Programmar Semantic Tree (PST) is complete. After parsing is complete, a report like the following can be generated to show the troublesome snippets of code. |
 |
| Frequency counts are very useful for transformation purposes. Elements with only a few instances can be replaced before transformation, or transformed manually. |
| Notice that everything is anonymous in the traditional grammar. |
 |
An overview of active projects and programming languages. This is just an image.
In the actual application, you can drill down by project or by language, etc.
One of many reports available to peruse files in a project. You can see many parsing statistics such as elapsed time in milliseconds, lines per second, tokens per line, etc.
An example of a Parse failure. Shows the error location and the programmar stack at that point.
For more information and to get involved in this exciting opportunity, please contact us at info@eaglegacy.com
Last updated: 9/14/2018