Heading:

Using PGS

Page Numbers: Yes X: 527 Y: 10.5"

Inter-Office Memorandum

ToPGS UsersDateFebruary 15, 1982

FromEd SatterthwaiteLocationPalo Alto

SubjectUsing PGSOrganizationPARC/CSL

XEROX

Filed on: [Ivy]<Satterthwaite>PGS.BravoDRAFT

I have revised PGS to handle module identifiers, file names, etc., in the currently approved way and to allow easier parameterization with respect to long or short pointers. The basic idea is to make PGS more like the compiler and binder in these areas (to avoid the current file name hassles and to make PGS more usable by the system modeller).

This memo supplements The Mesa Parser Generator System by James Eve, which remains the primary documentation. It is referenced below as Mesa PGS and can be found on [Igor]<Eve>PGS.press).

Processing Modes

Input: Mesa vs. grammar. PGS can extract the information needed to build parsing tables from comments embedded within standard Mesa source files. Although Mesa PGS documents this input mode almost as an afterthought, it has become the standard one. The grammar mode has been retained for its occasional utility in experimenting with grammars. See Mesa PGS Appendix.

Output: BCD vs. binary. The usual output mode is BCD; this facilitates packaging the parsing tables with the code that uses them (in a BCD, boot or image file). The binary mode has been retained primarily for situations in which the parsing tables are to be used by non-Mesa programs.

Mesa Programs as PGS Source Files

The list of keywords that optionally precede the first production has been revised and expanded as follows:

TABLE:
TYPE:
EXPORTS:
GOAL:
TERMINALS:
ALIASES:
PRODUCTIONS:

The first three must precede all the others but may occur in any order; the next section explains their significance. The last four must appear in the specified order; all but the last may be omitted.

Output Identification

In the source text, the old keywords dealing with file and module names are replaced by

TABLE: tableId TYPE: typeId EXPORTS: interfaceId -- or EXPORTS: SELF

This is supposed to remind you of

programId: <ProgramType> EXPORTS interfaceId

(sorry about the different treatment of colons, etc.). The names tableId, typeId and interfaceId are module identifiers (capitalization counts) and get put into BCDs, symbol tables, etc.

Examples

The following examples are taken from the current system. The compiler and binder specify the same type name because they use the same parsing module, in which that interface is a (compile-time) parameter. On the other hand, they export different interfaces because loading of the corresponding tables is handled differently (see below).

TABLE: BCDParseData TYPE: ParseTable EXPORTS: SELF-- binder

TABLE: MesaTab TYPE: ParseTable EXPORTS: CBinary-- compiler

TABLE: PGSParseData TYPE: PGSParseTable EXPORTS: SELF-- PGS

Invoking PGS

Command Line Syntax

paragraph

File Naming

When you invoke PGS, you can specify an arbitrary association between files and module identifiers using the same command-line conventions that the compiler and binder do. The most general form is:

[defs: defsFile, bcd: bcdFile, grammar: grammarFile] ←
sourceFile[interfaceId: interfaceFile]/switches

which puts

the source for the interface typeId on defsFile.mesa,
the BCD for the tableId (or binary, if you say "binary:") on bcdFile.bcd (or .binary),
a summary of the grammar on grammarFile.grammar (only if input was a Mesa source file)

and finds the BCD for interfaceId on interfaceFile.bcd. Capitalization doesn’t count here. By default

defsFile: typeId.mesa
bcdFile: tableId.mesa
grammarFile: tableId.grammar (inhibit with /-g)
error messages: tableId.pgslog

(There are further defaults for the cases in which the input is just a grammar file or you omit keyword items for the module identifiers in the source).

Note that the new use of keywords is not compatible with existing use.

Keywords

Paragraph.

Feedback

Paragraph.

Using PGS Output

Paragraph.

Distribution:
Mesa Group