Browse Prior Art Database

Automatic Template Request Generation for Languages

IP.com Disclosure Number: IPCOM000035379D
Original Publication Date: 1989-Jul-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 3 page(s) / 17K

Publishing Venue

IBM

Related People

Lawlor, FD: AUTHOR

Abstract

The area of language-based, or grammar-directed, editing is a growing area of interest. One of the primary facilities (and sometimes the only one) provided by the language-based editors is something called "templates". For example, for an IF/THEN/ELSE statement, the template might look like: IF THEN ELSE

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 1 of 3

Automatic Template Request Generation for Languages

The area of language-based, or grammar-directed, editing is a growing area of interest. One of the primary facilities (and sometimes the only one) provided by the language-based editors is something called "templates". For example, for an IF/THEN/ELSE statement, the template might look like: IF <conditional> THEN <statement> ELSE <statement>

This simplifies entry for novice programmers, slow typists, and unfamiliar language constructs.

Some mechanism is needed to request the desired template. Generally, this is some special key combination or command. As the complexity of the language increases and the user wishes more sophisticated template variations, however, requesting the template becomes as complex as typing the language construct itself. The template approach is also at odds with the approach of users who just want to type what they know, but who might need some help.

In one prior-art editor, by simply typing ELSE, for example, the user could get an IF/THEN/ELSE template. This approach overcame the need for special commands to request templates and merged the template and "type what you know" approaches.

This approach required, however, a laborious and error-prone human analysis of the possible error situations, the recovery from them and a lot of handcoded logic to implement the recovery. For a large language (e.g., ADA), this task could be enormous and language changes could require extensive reanalysis.

Since the legitimate and unambiguous templates possible in any language are inherent in the grammar of the language, a way was sought to derive the template definitions from the grammar.

Since the goal was to recognize certain normally incorrect inputs as valid template requests, one way was to view the task as one of defining an augmented grammar which would recognize the legitimate template requests. Specifying it as a grammar had a number of very desirable characteristics: - Recognition would not involve the inefficiency or complexity of novel error recovery procedures, but would require only standard, efficient parsing. - All the normal tools, tests and techniques for grammars could be applied to the augmented grammar (e.g., automatic parser generation, recovery, ambiguity tests, debugging, etc.).

This significantly improved the performance and quality of the template generator while significantly reducing its size and development cost.

The augmented grammar productions could be derived from the original grammar itself by recognizing that a valid template request would be any input which was an unambiguous subset of the original grammar.

Assuming a grammar notation which allows optional terms

1

Page 2 of 3

(terminals or non-terminals) and a parser generator which allows incremental addition/deletion of productions, then all the unambiguous template requests could be determined by the following "front-end" to the parser generator (this is a rough outline of the unopti...