Skip to content

Commit 2f24229

Browse files
committed
Add section on notational conventions
1 parent 140abf3 commit 2f24229

File tree

5 files changed

+224
-111
lines changed

5 files changed

+224
-111
lines changed

Appendix A -- Notation Conventions.md

Lines changed: 193 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,193 @@
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+

GraphQL.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -55,3 +55,5 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
5555
# [Response](Section 7 -- Response.md)
5656

5757
# [Grammar](Section 8 -- Grammar.md)
58+
59+
# [Appendix: Notation Conventions](Appendix A -- Notation Conventions.md)

Section 6 -- Execution.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -90,12 +90,12 @@ CollectFields(objectType, selectionSet, visitedFragments):
9090

9191
doesFragmentTypeApply(objectType, fragmentType):
9292

93-
* If {fragmentType} is an Object Type, return {true} if {objectType} is
94-
{fragmentType}, otherwise return {false}.
95-
* If {fragmentType} is an Interface Type, return {true} if {objectType} is an
96-
implementation of {fragmentType}, otherwise return {false}.
97-
* If {fragmentType} is a Union, return {true} if {objectType} is a possible
98-
type of {fragmentType}, otherwise return {false}.
93+
* If {fragmentType} is an Object Type:
94+
* if {objectType} and {fragmentType} are the same type, return {true}, otherwise return {false}.
95+
* If {fragmentType} is an Interface Type:
96+
* if {objectType} is an implementation of {fragmentType}, return {true} otherwise return {false}.
97+
* If {fragmentType} is a Union:
98+
* if {objectType} is a possible type of {fragmentType}, return {true} otherwise return {false}.
9999

100100
The result of evaluating the selection set is the result of evaluating the
101101
corresponding grouped field set. The corresponding grouped field set should be

0 commit comments

Comments
 (0)