typo
[web.git] / personal / _posts / 2018-04-05-a-formal-look-at-pinning.md
index 2e72c2a6a73f3a7ef004bf939872c642257a4fb5..edaf6c64632381a5783fec2eec4dfb3a125660e6 100644 (file)
@@ -15,7 +15,7 @@ But before we get started, I have to lay down some basics.
 
 ## Rust types: Recap
 
-I have discussed my model of Rust types [in a previous post]({{ site.baseurl }}{% post_url 2018-01-31-sharing-for-a-lifetime %}); this may me a good time to read that post as I will be using it as a starting point.
+I have discussed my model of Rust types [in a previous post]({% post_url 2018-01-31-sharing-for-a-lifetime %}); this may me a good time to read that post as I will be using it as a starting point.
 The short version is that I view Rust types with private invariants as not having just a single invariant, but different invariants that reflect the different "modes" the type can be in.
 @cramertj suggested to use "typestate" as terminology here, and I agree that this makes sense.
 
@@ -111,7 +111,7 @@ In contrast, converting `Box<T>` to `PinBox<T>` is fine because this *consumes*
 `Pin` lets us give a type to `SelfReferantial` that makes it safe to use.
 This is in the best tradition of Rust: We are using an expressive type system to provide safe APIs for operations that only have unsafe APIs in other languages (e.g., iterators that avoid iterator invalidation which plague even memory safe languages like Java).
 In the following, I will explain how one can prove that our claim of safe encapsulation actually holds true.
-This is building on the framework that we developed for the [RustBelt paper]({{ site.baseurl }}{% post_url 2017-07-08-rustbelt %}).
+This is building on the framework that we developed for the [RustBelt paper]({% post_url 2017-07-08-rustbelt %}).
 
 ## Formal Notation