Mirror: The magical sticky regex-based parser generator 🧙
Fix doc typos (#3)
authored by
chocolateboy
and committed by
GitHub
aa069a04
0f98c7fe
+15
-15
+15
-15
README.md
+15
-15
README.md
···
69
69
read back their updated `regex.lastIndex`.
70
70
71
71
> **Note:** Sticky Regexes aren't natively
72
-
> [supported in all versions of Internet Explorer](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/sticky#Browser_compatibility). `reghex` works around this by imitating its behaviour, which may decrease performance on IE11.
72
+
> [supported in any versions of Internet Explorer](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/sticky#Browser_compatibility). `reghex` works around this by imitating its behaviour, which may decrease performance on IE11.
73
73
74
74
This primitive allows us to build up a parser from regexes that you pass when
75
75
authoring a parser function, also called a "matcher" in `reghex`. When `reghex` compiles
···
178
178
**nested abstract output**.
179
179
180
180
We can also see in this example that _outside_ of the regex interpolations,
181
-
whitespaces and newlines don't matter.
181
+
whitespace and newlines don't matter.
182
182
183
183
```js
184
184
import { parse } from 'reghex';
···
200
200
`${/pattern/}`, or with other matchers `${name}`.
201
201
202
202
The tagged template syntax supports more ways to match these interpolations,
203
-
using a regex-like Domain Specific Language. Unlike in regexes, whitespaces
204
-
and newlines don't matter to make it easier to format and read matchers.
203
+
using a regex-like Domain Specific Language. Unlike in regexes, whitespace
204
+
and newlines don't matter, which makes it easier to format and read matchers.
205
205
206
206
We can create **sequences** of matchers by adding multiple expressions in
207
207
a row. A matcher using `${/1/} ${/2/}` will attempt to match `1` and then `2`
···
210
210
211
211
| Operator | Example | Description |
212
212
| -------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
213
-
| `?` | `${/1/}?` | An **optional** may be used to make an interpolation optional. This will mean that the interpolation may or may not match. |
214
-
| `*` | `${/1/}*` | A **star** can be used to match an arbitrary amount of interpolation or none at all. This will mean that the interpolation may repeat itself or may not be matched at all. |
213
+
| `?` | `${/1/}?` | An **optional** may be used to make an interpolation optional. This means that the interpolation may or may not match. |
214
+
| `*` | `${/1/}*` | A **star** can be used to match an arbitrary amount of interpolation or none at all. This means that the interpolation may repeat itself or may not be matched at all. |
215
215
| `+` | `${/1/}+` | A **plus** is used like `*` and must match one or more times. When the matcher doesn't match, that's considered a failing case, since the match isn't optional. |
216
216
| `\|` | `${/1/} \| ${/2/}` | An **alternation** can be used to match either one thing or another, falling back when the first interpolation fails. |
217
-
| `()` | `(${/1/} ${/2/})+` | A **group** can be used apply one of the other operators to an entire group of interpolations. |
218
-
| `(?: )` | `(?: ${/1/})` | A **non-capturing group** is like a regular group, but whatever the interpolations inside it will match, won't appear in the parser's output. |
219
-
| `(?= )` | `(?= ${/1/})` | A **positive lookahead** will check whether interpolations match, and if so will continue the matcher without changing the input. If it matches it's essentially ignored. |
220
-
| `(?! )` | `(?! ${/1/})` | A **negative lookahead** will check whether interpolations _don't_ match, and if so will continue the matcher without changing the input. If the interpolations do match the mathcer will be aborted. |
217
+
| `()` | `(${/1/} ${/2/})+` | A **group** can be used to apply one of the other operators to an entire group of interpolations. |
218
+
| `(?: )` | `(?: ${/1/})` | A **non-capturing group** is like a regular group, but the interpolations matched inside it don't appear in the parser's output. |
219
+
| `(?= )` | `(?= ${/1/})` | A **positive lookahead** checks whether interpolations match, and if so continues the matcher without changing the input. If it matches, it's essentially ignored. |
220
+
| `(?! )` | `(?! ${/1/})` | A **negative lookahead** checks whether interpolations _don't_ match, and if so continues the matcher without changing the input. If the interpolations do match the matcher is aborted. |
221
221
222
222
We can combine and compose these operators to create more complex matchers.
223
223
For instance, we can extend the original example to only allow a specific set
···
262
262
parse(name)('tim'); // undefined
263
263
```
264
264
265
-
Lastly, like with regexex `?`, `*`, and `+` may be used as "quantifiers". The first two
265
+
Lastly, like with regexes, `?`, `*`, and `+` may be used as "quantifiers". The first two
266
266
may also be optional and _not_ match their patterns without the matcher failing.
267
267
The `+` operator is used to match an interpolation _one or more_ times, while the
268
268
`*` operators may match _zero or more_ times. Let's use this to allow the `"!"`
···
286
286
287
287
In the previous sections, we've seen that the **nodes** that `reghex` outputs are arrays containing
288
288
match strings or other nodes and have a special `tag` property with the node's type.
289
-
We can **change this output** while we're parsing by passing a second function to our matcher definition.
289
+
We can **change this output** while we're parsing by passing a function to our matcher definition.
290
290
291
291
```js
292
292
const name = match('name', (x) => x[0])`
···
300
300
second argument. This will change the matcher's output, which causes the parser to
301
301
now return a new output for this matcher.
302
302
303
-
We can use this function creatively by outputting full AST nodes, maybe like the
304
-
ones even that resemble Babel's output:
303
+
We can use this function creatively by outputting full AST nodes, maybe even like the
304
+
ones that resemble Babel's output:
305
305
306
306
```js
307
307
const identifier = match('identifier', (x) => ({
···
316
316
317
317
We've now entirely changed the output of the parser for this matcher. Given that each
318
318
matcher can change its output, we're free to change the parser's output entirely.
319
-
By **returning a falsy** in this matcher, we can also change the matcher to not have
319
+
By **returning a falsy value** in this matcher, we can also change the matcher to not have
320
320
matched, which would cause other matchers to treat it like a mismatch!
321
321
322
322
```js