|
⇤ ← Revision 1 as of 2006-12-17 16:47:06
Size: 1640
Comment:
|
Size: 2879
Comment: Types
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 14: | Line 14: |
| || `CSymbol` || Capitalized identifier || | || `Symbol` || Identifier starting with a lowercase letter || || `CSymbol` || Identifier starting with a capital letter || |
| Line 29: | Line 30: |
= Types = Types describe expressions. As is standard in statically-typed programming languages, they are used only for validation purposes and have no real effect on the "output" of a program. The following table gives the grammar of types `T`. The section on expressions will give the meanings of types in terms of which expressions have which types. || '''Syntax''' || '''Description''' || || `Symbol` || Extern type || || `[T]` || List of `T`s || || `T1 -> T2` || Function from `T1` to `T2` || || `[P]` || Action allowed only when `P` is satisified; requires no environment variables on input and writes none of its own || || `[P] {CSymbol1 : T1, ..., CSymbolN : TN}` || Action that requires environment variables `CSymbol1`, ..., `CSymbolN` to have the given types when run || || `[P] {CSymbol1_1 : T1_1, ..., CSymbol1_N : T1_N} => {CSymbol2_1 : T2_1, ..., CSymbol2_M : T2_M}` || Like the last case, but the second set of typed environment variables describes what the action will write || || `P => T` || A nested action that requires that its nested configuration satisfy `P`; `T` should be some action type || || `(T)` || Grouping || |
This page gives an in-depth specification of the DomTool language. Most members would probably prefer the more informal presentation in DomTool/UserGuide.
1. Source code
For a complete, precise, and accurate grammatical specification, see the lexer and parser specifications src/domtool.lex and src/domtool.grm in the DomTool source code. See src/tycheck.sml for the type-checker implementation. ["DomTool/Building"] has information on obtaining the source.
2. Token conventions
In the grammars that follow, we use these lexical token class names:
Name |
Description |
Symbol |
Identifier starting with a lowercase letter |
CSymbol |
Identifier starting with a capital letter |
3. Predicates
DomTool uses predicates to describe in what contexts an action may occur. For instance, web-related actions should only occur inside the scope of a virtual host directive. Predicates are built up following the grammar in the table below, using the letter P as the non-terminal for predicates.
Meanings are given as statements that must hold about the context where an action is found. The context is represented as a stack of context IDs which have been declared with context declarations.
Syntax |
Description |
Meaning |
Root |
Root |
The stack is empty. |
CSymbol |
Context ID |
CSymbol is on the top of the stack. |
^P |
Suffixes |
Some (not necessarily strict) suffix of the stack matches P. |
!P |
Not |
The stack doesn't match P. |
P1 & P2 |
And |
The stack matches both P1 and P2. |
(P) |
Grouping |
Identical to P |
4. Types
Types describe expressions. As is standard in statically-typed programming languages, they are used only for validation purposes and have no real effect on the "output" of a program. The following table gives the grammar of types T. The section on expressions will give the meanings of types in terms of which expressions have which types.
Syntax |
Description |
Symbol |
Extern type |
[T] |
List of Ts |
T1 -> T2 |
Function from T1 to T2 |
[P] |
Action allowed only when P is satisified; requires no environment variables on input and writes none of its own |
[P] {CSymbol1 : T1, ..., CSymbolN : TN} |
Action that requires environment variables CSymbol1, ..., CSymbolN to have the given types when run |
[P] {CSymbol1_1 : T1_1, ..., CSymbol1_N : T1_N} => {CSymbol2_1 : T2_1, ..., CSymbol2_M : T2_M} |
Like the last case, but the second set of typed environment variables describes what the action will write |
P => T |
A nested action that requires that its nested configuration satisfy P; T should be some action type |
(T) |
Grouping |