shadowfacts
/
v6
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix typo

This commit is contained in:
Shadowfacts 2024-01-01 16:39:25 -05:00
parent 78cbdb100c
commit c54a5c273d
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
site/posts/2023-12-27-parsing-html-fast.md
View File

@ -72,7 +72,7 @@ This was one of the more surprising optimizations I made, since I'd expected thi
Lots of states of the tokenizer involve building up the current token until it's ready to emit. This means the parser needs to store the in-progress token. My `Token` data type is a Swift enum with a handful of different cases. So, the natural way of representing the current token was as an instance variable of an optional `Token`. Modifying the current token means, then, pattern matching against a `Token` and then constructing the updated `Token` and assigning it back.
Unfortunately, this does not permit in-place modification, meaning that all of the enum's associated values need to be copied. For primitive times, this might not be a problem. But for more complex types, like arrays and strings, this results in a bunch of extra copies. So, rather than having a single `currentToken` property, there are separate properties representing the data for each possible token—each of which can be modified in-place:
Unfortunately, this does not permit in-place modification, meaning that all of the enum's associated values need to be copied. For primitive types, this might not be a problem. But for more complex types, like arrays and strings, this results in a bunch of extra copies. So, rather than having a single `currentToken` property, there are separate properties representing the data for each possible token—each of which can be modified in-place:
```swift
private var currentToken: Token?