From c54a5c273d544422ecdf73ddf0b96442d4555c0f Mon Sep 17 00:00:00 2001 From: Shadowfacts Date: Mon, 1 Jan 2024 16:39:25 -0500 Subject: [PATCH] Fix typo --- site/posts/2023-12-27-parsing-html-fast.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/posts/2023-12-27-parsing-html-fast.md b/site/posts/2023-12-27-parsing-html-fast.md index 92cddb4..9ba5347 100644 --- a/site/posts/2023-12-27-parsing-html-fast.md +++ b/site/posts/2023-12-27-parsing-html-fast.md @@ -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?