|
| 1 | +# A. Appendix: Notation Conventions |
| 2 | + |
| 3 | +This specification document contains a number of notation conventions used to |
| 4 | +describe technical concepts such as language grammar and semantics as well as |
| 5 | +runtime algorithms. |
| 6 | + |
| 7 | +This appendix seeks to explain these notations in greater detail to |
| 8 | +avoid ambiguity. |
| 9 | + |
| 10 | + |
| 11 | +## Context-Free Grammar |
| 12 | + |
| 13 | +A context-free grammar consists of a number of productions. Each production has |
| 14 | +an abstract symbol called a "non-terminal" as its left-hand side, and zero or |
| 15 | +more possible sequences of non-terminal symbols and or terminal characters as |
| 16 | +its right-hand side. |
| 17 | + |
| 18 | +Starting from a single goal non-terminal symbol, a context-free grammar |
| 19 | +describes a language: the set of possible sequences of characters that can be |
| 20 | +described by repeatedly replacing any non-terminal in the goal sequence with one |
| 21 | +of the sequences it is defined by, until all non-terminal symbols have been |
| 22 | +replaced by terminal characters. |
| 23 | + |
| 24 | +Terminals are represented in this document in a monospace font in two forms: a |
| 25 | +specific unicode character or sequence of unicode characters (ex. {`=`} or {`terminal`}), and a pattern of unicode characters defined by a regular expression |
| 26 | +(ex {/[0-9]+/}). |
| 27 | + |
| 28 | +Non-terminal production rules are represented in this document using the |
| 29 | +following notation for a non-terminal with a single definition: |
| 30 | + |
| 31 | +NonTerminalWithSingleDefinition : NonTerminal `terminal` |
| 32 | + |
| 33 | +While using the following notation for a production with a list of definitions: |
| 34 | + |
| 35 | +NonTerminalWithManyDefinitions : |
| 36 | + - OtherNonTerminal `terminal` |
| 37 | + - `terminal` |
| 38 | + |
| 39 | +A definition may refer to itself, which describes repetitive sequences, |
| 40 | +for example: |
| 41 | + |
| 42 | +ListOfLetterA : |
| 43 | + - `a` |
| 44 | + - ListOfLetterA `a` |
| 45 | + |
| 46 | + |
| 47 | +## Lexical and Syntactical Grammar |
| 48 | + |
| 49 | +The GraphQL language is defined in a syntactic grammar where terminal symbols |
| 50 | +are tokens. Tokens are defined in a lexical grammar which matches patterns of |
| 51 | +source characters. The result of parsing a sequence of source unicode characters |
| 52 | +produces a GraphQL AST. |
| 53 | + |
| 54 | +A Lexical grammar production describes non-terminal "tokens" by |
| 55 | +patterns of terminal unicode characters. No "whitespace" or other ignored |
| 56 | +characters may appear between any terminal unicode characters in the lexical |
| 57 | +grammar production. A lexical grammar production is distinguished by a two colon |
| 58 | +`::` definition. |
| 59 | + |
| 60 | +Word :: /[A-Za-z]+/ |
| 61 | + |
| 62 | +A Syntactical grammar production describes non-terminal "rules" by patterns of |
| 63 | +terminal Tokens. Whitespace and other ignored characters may appear before or |
| 64 | +after any terminal Token. A syntactical grammar production is distinguished by a |
| 65 | +one colon `:` definition. |
| 66 | + |
| 67 | +Sentence : Noun Verb |
| 68 | + |
| 69 | + |
| 70 | +## Grammar Notation |
| 71 | + |
| 72 | +This specification uses some additional notation to describe common patterns, |
| 73 | +such as optional or repeated patterns, or parameterized alterations of the |
| 74 | +definition of a non-terminal. This section explains these short-hand notations |
| 75 | +and their expanded definitions in the context-free grammar. |
| 76 | + |
| 77 | + |
| 78 | +**Constraints** |
| 79 | + |
| 80 | +A grammar production may specify that certain expansions are not permitted by |
| 81 | +using the phrase "but not" and then indicating the expansions to be excluded. |
| 82 | + |
| 83 | +For example, the production: |
| 84 | + |
| 85 | +SafeName : Name but not SevenCarlinWords |
| 86 | + |
| 87 | +means that the nonterminal {SafeName} may be replaced by any sequence of |
| 88 | +characters that could replace {Name} provided that the same sequence of |
| 89 | +characters could not replace {SevenCarlinWords}. |
| 90 | + |
| 91 | +A grammar may also list a number of restrictions after "but not" seperated |
| 92 | +by "or". |
| 93 | + |
| 94 | +For example: |
| 95 | + |
| 96 | +NonBooleanName : Name but not `true` or `false` |
| 97 | + |
| 98 | + |
| 99 | +**Optionality and Lists** |
| 100 | + |
| 101 | +A subscript suffix "{Symbol?}" is shorthand for two possible sequences, one |
| 102 | +including that symbol and one excluding it. |
| 103 | + |
| 104 | +As an example: |
| 105 | + |
| 106 | +Sentence : Noun Verb Adverb? |
| 107 | + |
| 108 | +is shorthand for |
| 109 | + |
| 110 | +Sentence : |
| 111 | + - Noun Verb |
| 112 | + - Noun Verb Adverb |
| 113 | + |
| 114 | +A subscript suffix "{Symbol+}" is shorthand for a list of |
| 115 | +one or more of that symbol. |
| 116 | + |
| 117 | +As an example: |
| 118 | + |
| 119 | +Book : Cover Page+ Cover |
| 120 | + |
| 121 | +is shorthand for |
| 122 | + |
| 123 | +Book : Cover Page_list Cover |
| 124 | + |
| 125 | +Page_list : |
| 126 | + - Page |
| 127 | + - Page_list Page |
| 128 | + |
| 129 | + |
| 130 | +**Parameterized Grammar Productions** |
| 131 | + |
| 132 | +A symbol definition subscript suffix parameter in braces "{Symbol[Param]}" |
| 133 | +is shorthand for two symbol definitions, one appended with that parameter name, |
| 134 | +the other without. The same subscript suffix on a symbol is shorthand for that |
| 135 | +variant of the definition. If the parameter starts with "?", that |
| 136 | +form of the symbol is used if in a symbol definition with the same parameter. |
| 137 | +Some possible sequences can be included or excluded conditionally when |
| 138 | +respectively prefixed with "\[+Param]" and "\[~Param]". |
| 139 | + |
| 140 | +As an example: |
| 141 | + |
| 142 | +Example[Param] : |
| 143 | + - A |
| 144 | + - B[Param] |
| 145 | + - C[?Param] |
| 146 | + - [+Param] D |
| 147 | + - [~Param] E |
| 148 | + |
| 149 | +is shorthand for |
| 150 | + |
| 151 | +Example : |
| 152 | + - A |
| 153 | + - B_param |
| 154 | + - C |
| 155 | + - E |
| 156 | + |
| 157 | +Example_param : |
| 158 | + - A |
| 159 | + - B_param |
| 160 | + - C_param |
| 161 | + - D |
| 162 | + |
| 163 | + |
| 164 | +## Grammar Semantics |
| 165 | + |
| 166 | +This specification describes the semantic value of many grammar productions in |
| 167 | +the form of a list of algorithmic steps. |
| 168 | + |
| 169 | +For example, this describes how a parser should interpret a unicode escape |
| 170 | +sequence which appears in a string literal: |
| 171 | + |
| 172 | +EscapedUnicode :: u /[0-9A-Fa-f]{4}/ |
| 173 | + |
| 174 | + * Let {codePoint} be the number represented by the four-digit hexidecimal sequence. |
| 175 | + * The string value is the unicode character represented by {codePoint}. |
| 176 | + |
| 177 | + |
| 178 | +## Algorithms |
| 179 | + |
| 180 | +This specification describes some algorithms used by the static and runtime semantics, they're defined in the form of a function-like syntax along with a |
| 181 | +list of algorithmic steps to take. |
| 182 | + |
| 183 | +For example, this describes if a fragment should be spread into place given a |
| 184 | +runtime {objectType} and the fragment's {fragmentType}: |
| 185 | + |
| 186 | +doesFragmentTypeApply(objectType, fragmentType): |
| 187 | + * If {fragmentType} is an Object Type: |
| 188 | + * if {objectType} and {fragmentType} are the same type, return {true}, otherwise return {false}. |
| 189 | + * If {fragmentType} is an Interface Type: |
| 190 | + * if {objectType} is an implementation of {fragmentType}, return {true} otherwise return {false}. |
| 191 | + * If {fragmentType} is a Union: |
| 192 | + * if {objectType} is a possible type of {fragmentType}, return {true} otherwise return {false}. |
| 193 | + |
0 commit comments