grammar fixes in 2023-01-20-types-announcement.md

posts/2023-01-20-types-announcement.md

@@ -42,9 +42,9 @@ As mentioned above, a nearly essential element of the growing Rust language is t
 
 As far back as 2015, not long after the release of Rust 1.0, an experimental Rust trait solver called Chalk began to be written. The core idea of Chalk is to translate the surface syntax and ideas of the Rust trait system (e.g. traits, impls, where clauses) into a set of logic rules that can be solved using a Prolog-like solver. Then, once this set of logic and solving reaches parity with the trait solver within the compiler itself, the plan was to simply replace the existing solver. In the meantime (and continuing forward), this new solver could be used by other tools, such as rust-analyzer, where it is used today.
 
-Now, given Chalk's age and the promises it had been hoped to be able to deliver on, you might be tempted to ask the question "Chalk, when?" - and plenty have. However, we've learned over the years that Chalk is likely not the correct long-term solution for Rust, for a few reasons. First, as mentioned a few times in this post, the trait solver is only but a part of a larger type system; and modeling how the entire type system fits together gives a more complete picture of its details than trying to model the parts separately. Second, the needs of the *compiler* are quite different than the needs of a *formalization*: the compiler needs performant code with the ability to track information required for powerful diagnostics; a good formalization is one that is not only complete, but also easy to maintain, read, and understand. Over the years, Chalk has tried to have both and it has so far ended up with neither.
+Now, given Chalk's age and the promises it had been hoped it would be able to deliver on, you might be tempted to ask the question "Chalk, when?" - and plenty have. However, we've learned over the years that Chalk is likely not the correct long-term solution for Rust, for a few reasons. First, as mentioned a few times in this post, the trait solver is only but a part of a larger type system; and modeling how the entire type system fits together gives a more complete picture of its details than trying to model the parts separately. Second, the needs of the *compiler* are quite different than the needs of a *formalization*: the compiler needs performant code with the ability to track information required for powerful diagnostics; a good formalization is one that is not only complete, but also easy to maintain, read, and understand. Over the years, Chalk has tried to have both and it has so far ended up with neither.
 
-So, what are the plans going forward? Well, first the types team has begun working on a formalization of the Rust typesystem, currently coined [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality/). An initial experimental phase was written using [PLT redex](https://redex.racket-lang.org/), but a Rust port is in-progress. There's lot to do still (including modeling more of the trait system, writing an RFC, and moving it into the rust-lang org), but it's already showing great promise.
+So, what are the plans going forward? Well, first the types team has begun working on a formalization of the Rust typesystem, currently coined [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality/). An initial experimental phase was written using [PLT redex](https://redex.racket-lang.org/), but a Rust port is in-progress. There's a lot to do still (including modeling more of the trait system, writing an RFC, and moving it into the rust-lang org), but it's already showing great promise.
 
 Second, we've begun an [initiative](https://github.com/rust-lang/types-team/issues/58) for writing a new trait solver in-tree. This new trait solver is more limited in scope than a-mir-formality (i.e. not intending to encompass the entire type system). In many ways, it's expected to be quite similar to Chalk, but leverage bits and pieces of the existing compiler and trait solver in order to make the transition as painless as possible. We do expect it to be pulled out-of-tree at some point, so it's being written to be as modular as possible. During our types team meetup earlier this month, we were able to hash out what we expect the structure of the solver to look like, and we've already gotten that [merged into the source tree](https://github.com/rust-lang/rust/pull/105661).