Introduction

A template describes the transformation to perform to take the a command typed at the terminal or generated by a command programming language, (In either case a string of ASCII or EBCDIC text), and interpret it as a call type gate jump.
N.B. Some of the syntax may be best interpreted as more generalized programming language statements running in an environment with a small number of pre-defined variables.

<command-line> ::= <command> ^ <first-command> <pipe-string> <last-command>^ <first-command> <last-command>

<command> ::= <basic> ^ <basic> <pipe-to> ^ <basic> <pipe-from> ^ <basic> <pipe-to> <pipe-from> ^ <basic> <pipe-from> <pipe-to>

<first-command> ::= <basic> ^ <basic> <pipe-from>

<last-command> ::= <basic> ^ <basic> <pipe-to>

<pipe-from> ::= <<> <ekey-name>

<pipe-to> ::= <>> <key-name> ^ <>>> <key-name>

<^> ::= The vertical bar character "^".

<pipe-string> ::= <^> ^ <^><basic><pipe-string>
<<> ::= The less than character "<".

<>> ::= The greater than character ">".

<>>> ::= Two greater than characters ">>".

<basic> ::= <ekey-name> <order-code> <token-list> [ , <key-words> ] ^ <ekey-name>(<ordercode [, <parmstring>] [; [ <offered-key-list>]] ==> [ RETURNCODE ] [, RETURNSTRING ] [; <return-key-list>] ) ^ <ekey-name>( <ordercode> [, <parmstring>] [; [ <offered-key-list>]] ==> [ RETURNCODE ] ) <middle-list> <last-jump-spec>

<ekey-name> ::= # an existing key name #

<order-code> ::= # A character string specifing one of the operations defined by the kt of <ekey-name> #

<token-list> ::= ^ <token-list> <token>

<token> ::= <word> ^ <char-string> ^ <number> ^ <list>

<word> ::= # a string of non-blank printable characters not beginning with (, /, ' or " #

<char-string> ::= "<char-list>" ^ '<char-list>'

<char-list> ::= ^ <char-list><char>

<number> ::= <hex-string> ^ <decimal-number>
<hex-string> ::= '<hex-list>'X ^ '<hex-list>'x

<hex-list> ::= <hex-digit><hex-digit> ^ <hex-list> <blank> <hex-list> ^ <hex-list><hex-list>

<decimal-number> ::= <digit> ^ <decimal-number><digit>

<list> ::= ( <token-list> )

<key-words> ::= ^ <key-words> <blank> <key-value>

<key-value> ::= <label> <blank> <token>

<label> ::= <letter> ^ <label><letter> ^ <label><digit>

<Template> ::= <format> <command-spec> <jump-spec>

<format> ::= 0

BNF syntax:
<command-spec> ::= COMMAND <posistional-list> [, <key-word-list> ];

<posistional-list> ::= ^ <posistional-list> <blank> <posistional>

<posistional> ::= <var-spec> ^ <char-string> <blank> <var-spec>

<key-word-list> ::= <key-word> ^ <key-word-list> , <key-word>

<key-word> ::= <var-spec>

<var-spec> ::= <label> ^ ( <label> , <type> [, <help>] )

<type> ::= ANY ^ KEY ^ NKEY ^ EKEY ^ NUMBER ^ NULL ^ LIST ^ <type> / <type>

<help> ::= <char-string>

Semantics:
The <command-spec> string is used to parse a command from either a terminal or a command procedure. The command consists of a set of posistional parameters, optionally followed by the key word introducer character (a ","), followed by "keyword-value" parameter sequences. The command is scanned from left to right and divided into tokens at each occurrence of a blank. Embeded blanks may be included by enclosing the string in quotes (" or '). A list may be specified by enclosing the tokens in parenthesis "()". Each word is assigned to the associated <label> after its type has been checked. If the posistional parameters are exhausted before the end of the <posistional-list> then all remaining <label>s are assigned the null string. (They must include the type NULL in their type list.) After the key word interducer character is encountered all subsiquent tokens will be interperted as key word specifications. The <label> used in the template becomes the key word and its value is the string specified in the command.

When used interactivly, the <char-string>s in the <posistional-list> may be printed as prompts. (N.B. this is not currently implemented.) If the user requests help while a <var-spec> is being filled then its <help> will be displayed. If there is no <help> then the <label> will be displayed. If the user requests help when a key word is expected then a list of the valid key words will be displayed.

The built in labels.

KEY is assigned the name of the invoked key

ORDERCODE is assigned the value of the order code.

The types are:
ANY - Any non-null character string is acceptable

KEY - The string must be a valid key name.

NKEY - The string must be a valid non-existing key name.

EKEY - The string must be a valid existing key name.

NUMBER - The string must be a valid <number>.

NULL - The null character string is acceptable.

LIST - A list of tokens is acceptable

BNF syntax:
<jump-spec> ::= <only-jump-spec> ^ <first-jump-spec> <middle-list> <last-jump-spec>

<only-jump-spec> ::= KEY( <ordercode> [, <parmstring>] [; [ <offered-key-list>]] ==> [ RETURNCODE ] [, RETURNSTRING] [; [ <return-key-list>]] )

<first-jump-spec> ::= KEY( kt+5 [, <parmstring>] [; [ <offered-key-list>]] ==> [ RETURNCODE ] )

<middle-list> ::= ^ <middle-list> <middle-jump-spec>

<middle-jump-spec> ::= COKEY( kt+5 [, <parmstring>] [; [ <offered-key-list>]] ==> [ RETURNCODE ] )

<middle-jump-spec> ::= COKEY( <ordercode> [, <parmstring>] [; <offered-key-list>] ==> [ RETURNCODE ] )

<last-jump-spec> ::= COKEY( <ordercode> [, <parmstring>] [; [ <offered-key-list>]] ==> [ RETURNCODE ] [, RETURNSTRING] [; [ <return-key-list>]] )

<ordercode> ::= ORDERCODE ^ <ordercode> <arith-op> <arith-expression>

<add-op> ::= + ^ -

<multiply-op> ::= * ^ / ^ MOD

<arith-op> ::= <multiply-op> ^ <add-op>

<primary> ::= <label> ^ <number> ^ ( <arith-expression> )

<term> ::= <primary> ^ <term> <multiply-op> <primary>

<arith-expression> ::= <term> ^ <arith-expression> <add-op> <term> ^ <add-op> <factor>

<parmstring> ::= <parm> ^ ( <parm-list> )
<parm> ::= <expression> ^ (number , <expression> [, <conversion>] )
<conversion> ::= BIN ^ CHAR

<parm-list> ::= <parm> ^ <parm-list>,<parm>

<expression> ::= <char-string> ^ <arith-expression> ^ <label> ^ <expression><string-op><expression>

<string-op> ::= .. ^ ^^

<offered-key-list> ::= ^ <offered-key> ^ <offered-key> , <offered-key-list> ^ , <offered-key-list>
<offered-key> ::= <key-id> ^ (key-id [,
<type-list> ::= <number> ^ <type-list> , <number>

<default> ::= <key-id>

<return-key-list> ::= ^ <key-id> ^ <key-id> , <return-key-list> ^ , <return-key-list>

<key-id> ::= <expression>

Semantics:
The <jump-spec> is an extension of the syntax used in the manual and has the same meaning. The extension for the offered keys <offered-key> allows the specification of a <default> which is used when the associated <key-id> is NULL and a <type-list> which will produce an error if the alledged type of the key does not match one of the <number>s in the list. If no <default> is provided then the default is a zero data key. If no <type-list> is provided then no type checking is done.

The extension for the parm string allows numbers or <expressions> to be converted to binary (BIN) or left in character form (CHAR).

The operator <op> .. concatinates two strings with a period between them.

The operator <op> ^^ concatinates two strings.

Assume there is a key in your directory called AUXFILE that will perform file transfers to/from Tymcom 370 systems. Assume further that it has the operations GETSEGMENT, GETRECORD, and PUT.

If the template for AUXFILE GETSEGMENT is:

0 COMMAND newsegmentname (circuitkey, EKEY) (systemnumber, NUMBER) cmsfilename cmsfiletype (cmsfilemode, NULL) / project (psb, EKEY) (sb, EKEY) (meter, EKEY) ;

KEY(0, ( (4,systemnumber,BIN), (8,cmsfilename), (8,cmsfiletype), (2,cmsfilemode), (12,project) ); (psb,"spacebank",'0D0C'X), (meter,"meter",6), (sb,"spacebank",'0D0C'x), (circuitkey,,'20'x) ==> RETURNCODE; newsegmentname)

The command:
auxfile getsegment mystuff tymnet.me 142 profile exec

will result in the same call as the low level key call:
auxfile(0, ((4,142,bin),"profile exec "); spacebank, meter, spacebank, tymnet.me ==> returncode; mystuff)

The command:
auxfile getsegment mystuff tymnet.me 142 profile exec (sb specialbank project xfer

will result in the same call as the low level key call:
auxfile(0, ((4,142,bin),"profile exec xfer "); spacebank, meter, specialbank, tymnet.me ==> returncode; mystuff)

The current syntax requires string constants in the templates to be in quotes. As the resulting gate jumps in the example shows, this requirement results in lots of quotes that add little to the readibility or writeability of the language. REX has the feature that any undefined symbol is interperted as a string constant of itself e.g. UNDEFINED --> "UNDEFINED".

The example shows that a "concatanate with blank" operator could save a lot of ^^ " " sequences.

The string generated to pass to the key requires parsing within that domain. A protocol where k(oc,s1,s2,s3;... results in k(oc,((l1,n),(s1,l1),(l2,n),(s2,l2),(l3,n),(s3,l3));... would help. (It will also be necessary for programming language level functions.) What should n be? 2 and 4 seem the best candiates.

An associated problem with the compound strings. The template langauge should be able to specify that compound strings are or are not assembled with the length indicators.

<pattern-spec> is described by the following:
BNF syntax:
<pattern-spec> ::= PARSE INPUT <pattern-list>;

<pattern-list> ::= <var-spec> ^ <pattern-list> <pattern-select> <var-spec>

<pattern-select> ::= <char-string> ^ <== ^ <blank>

<var-spec> ::= <label> ^ ( <label> , <type> [, <help>] )

<type> ::= ANY ^ DEC ^ HEX ^ KEY ^ NKEY ^ EKEY ^ NUMBER ^ OPTION ^ <type> / <type>

<help> ::= <char-string>

Semantics:
The <pattern-select> string is used to parse the input string typed by the user. The input string is scaned from the current posistion to the next occurence of the string specified in <pattern-select>. Any characters before the <pattern-select> string are assigned to the variable to its left. The scan cursor is placed at the character following the <pattern-select> string and the next <var-spec> <pattern-select> pair is processed. The symbol <== causes the input string to be re-scanned from the start. A <blank> (blank character) <pattern-select> is treated as if the <pattern-select> string was " ". The last <var-spec> in the <pattern-spec> is assigned all the remaining characters. If the input string is exhausted before the end of the <pattern-list> then all remaining <label>s are assigned the null string.

If the user requests help while scanning for a <pattern-select> then the <help> from the previous <var-spec> (the one being filled) will be displayed. If there is no <help> then the <label> will be displayed.

The built in labels.

KEY is assigned the name of the invoked key

ORDERCODE is assigned the value of the order code.

The types are:
ANY - Any character string is acceptable

DEC - The string must be a valid <decimal-number>.

HEX - The string must be a valid <hex-number>.

KEY - The string must be a valid key name.

NKEY - The string must be a valid non-existing key name.

EKEY - The string must be a valid existing key name.

NUMBER - The string must be a valid <number>.

OPTION - The variable <label> will be set to the character value of the following <pattern-select> string if it is found. Otherwise <label> will be set to the NULL string.

Current problems
There is a bug in the example in that "sb " will also match "psb ".

This system provides no way to remove leading and trailing blanks from the string. The kludge REX uses to "solve" the problem is that if and only if the <selector> is a <blank> then the leading and trailing blanks will be removed from the previous token.

The re-scan operator <== makes it difficult to provide help for the order free keywords. Perhaps some syntax e.g. [ ... ^ ... ] to choose one based on the first keyword found and { ... ^ ...} to search for the first keyword found, parse the string as specified and repeat to the end of the string. This change would also fix the confusion (bug) in the example if the project is " sb " by replacing the parse part of the template after cmsfileid by:

"(" { '"' projectcode '"' ^ "psb " (psb,EKEY) " " ^ "sb " (sb,EKEY) " " ^ "meter " (meter,EKEY) " " }

The current syntax requires string constants to be in quotes. As the resulting gate jumps in the examples show, this requirement results in lots of quotes that add little to the readibility or writeability of the language. REX has the feature that any undefined symbol is interperted as a string constant of itself e.g. UNDEFINED --> "UNDEFINED".

The string generated to pass to the key requires parsing within that domain. A protocol where k(oc,s1,s2,s3;... results in
k(oc,((l1,n),(s1,l1),(l2,n),(s2,l2),(l3,n),(s3,l3));... would help. (It will also be necessary for programming language level functions.) What should n be. 2 and 4 seem the best candiates.

There needs to be a way to write an arithmetic expression for the ORDERCODE.

An associated problem with the compound strings. The template langauge should be able to specify that compouund strings are or are not assembled with the length indicators.

Counter proposal for Syntax ACB
I am afraid that I favor a user language that is either one of the following:
Very English like with flexible word order and optional filler words. This is so difficult to do that I do not seriously propose that we attempt it.

Very predictable so that someone that knew what keys and strings were needed and what strings and keys were returned could enter the command without looking it up. This may make the language look very low level but I think not. There is a single GNOSIS primitave that applies to all levels of complexity. The model is the key call. All work in GNOSIS is accomplished by invoking keys. Well here it is by example not in BNF.

KEY ORDERCODE (string:key1,..keyn) ==> RETURNCODE (string:key1,..keyn);

"string" can be specified as either constants or variable names as follows:
str1,str2,str3 compound strings where strn is of the following

"abc" or variablename or strn ]
]
strn concatenated.

Each piece of the compound string is assembled with a leading halfword of count.

AUXFILE GETSEGMENT ("142","profile exec":,,,TYMNET.ME) ==> RC (:mystuff);

AUXFILE GETSEGMENT
(sysno,filename,project:,SB,M,SB,TYMNET.ME) ==> (:MYSTUFF);

AUXFILE GETSEGMENT (sysno,filename]
]
" "]
]
filetype:,,,TYMNET.ME) ==> (:MYSTUFF);

RC GETEQUAL (name:) ==> (:key);

RC PUTNEW (name:key) ==> RC;

NODE NODESWAP+5 (:newkey) ==> (:oldkey);

Mostly the templates hold true without modification. The sysno string could specify DEC and thus be written 142 instead of "142" but I would prefer that whatever it be it be the same throughout the world. Strings that are sometimes HEX and sometimes ASCII present a problem. If the key always wants ASCII or HEX then the template could do the conversion. But as the RC wants the name to be binary if it is ENTRY sequence there would have to be separate templates for the two types of RC. This has some attractions thus:

RC GETNEXT (12:) ==> (newname:key);

and
RC GETNEXT ("SSNUMBER":) ==> (ssnumber:key);

Interpret the string diffferently. The first is an entry sequence dataset so that the 12 is used as a binary number converted to 4 bytes of hex (as specified in the template) and returns a string withc is a 4 byte binary number. I don't like the ambiquity here but this is an unrelated problem to the difference between this syntactical proposal and Bill's. The same problem exists in both.