Merge pull request #329 from yaahc/type-interner

Rename TypeFamily to Interner

book/src/SUMMARY.md

@@ -5,8 +5,8 @@
 - [Contribution guide](./contribution_guide.md)
 - [REPL](./repl.md)
 - [Representing and manipulating Rust types](./types.md)
-    - [The role of the `TypeFamily`](./types/role_of_type_family.md)
-    - [Controlling representation with `TypeFamily`](./types/how_to_control_repr.md)
+    - [The role of the `Interner`](./types/role_of_interner.md)
+    - [Controlling representation with `Interner`](./types/how_to_control_repr.md)
     - [Rust types](./types/rust_types.md)
         - [Application types](./types/rust_types/application_ty.md)
     - [Rust lifetimes](./types/rust_lifetimes.md)

book/src/types.md

@@ -17,7 +17,7 @@ One of our goals is to create a type representation that can be
 readily embedded into a variety of contexts. Most specifically, we
 would like to be able to embed into rustc and rust-analyzer, and
 permit those two projects to use distinct memory management
-strategies. This is primarily achieved via the `TypeFamily` trait.
+strategies. This is primarily achieved via the `Interner` trait.
 
 Initially, at least in rustc, the goal is to be able to easily and
 "reasonably efficiently" convert back and forth between rustc's native
@@ -39,8 +39,8 @@ not been thoroughly discussed by the Rust compiler team as a whole.
 Here is a (partial) list of some things that have to be adapted in
 Chalk as of today to match this document:
 
-* `Parameter<TF>` needs to be renamed to `GenericArgument`
-* `Vec<Parameter<TF>>` needs to be replaced with `GenericArguments`
+* `Parameter<I>` needs to be renamed to `GenericArgument`
+* `Vec<Parameter<I>>` needs to be replaced with `GenericArguments`
 * Extract `TypeName` into something opaque to chalk-ir.
 * Dyn type equality should probably be driven by entailment.
 * Projections need to be renamed to aliases.

book/src/types/how_to_control_repr.md

@@ -1,36 +1,36 @@
-### Controlling representation with `TypeFamily`
+### Controlling representation with `Interner`
 
-The purpose of the [`TypeFamily`] trait is to give control over how
+The purpose of the [`Interner`] trait is to give control over how
 types and other bits of chalk-ir are represented in memory. This is
 done via an "indirection" strategy. We'll explain that strategy here
 in terms of [`Ty`] and [`TyData`], the two types used to represent
 Rust types, but the same pattern is repeated for many other things.
 
-[`TypeFamily`]: http://rust-lang.github.io/chalk/chalk_ir/family/trait.TypeFamily.html
+[`Interner`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
 [`Ty`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
 [`TyData`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyData.html
 
-Types are represented by a [`Ty<TF>`] type and the [`TyData<TF>`] enum.
+Types are represented by a [`Ty<I>`] type and the [`TyData<I>`] enum.
 There is no *direct* connection between them. The link is rather made
-by the [`TypeFamily`] trait, via the [`InternedTy`] associated type:
+by the [`Interner`] trait, via the [`InternedTy`] associated type:
 
-[`Ty<TF>`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
-[`TyData<TF>`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyData.html
-[`InternedTy`]: http://rust-lang.github.io/chalk/chalk_ir/family/trait.TypeFamily.html#associatedtype.InternedType
+[`Ty<I>`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
+[`TyData<I>`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyData.html
+[`InternedTy`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#associatedtype.InternedType
 
 ```rust,ignore
-struct Ty<TF: TypeFamily>(TF::InternedTy);
-enum TyData<TF: TypeFamily> { .. }
+struct Ty<I: Interner>(I::InternedTy);
+enum TyData<I: Interner> { .. }
 ```
 
-The way this works is that the [`TypeFamily`] trait has an associated
+The way this works is that the [`Interner`] trait has an associated
 type [`InternedTy`] and two related methods, [`intern_ty`] and [`ty_data`]:
 
-[`intern_ty`]: http://rust-lang.github.io/chalk/chalk_ir/family/trait.TypeFamily.html#tymethod.intern_ty
-[`ty_data`]: http://rust-lang.github.io/chalk/chalk_ir/family/trait.TypeFamily.html#tymethod.ty_data
+[`intern_ty`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#tymethod.intern_ty
+[`ty_data`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#tymethod.ty_data
 
 ```rust,ignore
-trait TypeFamily {
+trait Interner {
     type InternedTy;
     
     fn intern_ty(&self, data: &TyData<Self>) -> Self::InternedTy;
@@ -42,19 +42,19 @@ However, as a user you are not meant to use these directly. Rather,
 they are encapsulated in methods on the [`Ty`] and [`TyData`] types:
 
 ```rust,ignore
-impl<TF: TypeFamily> Ty<TF> {
-  fn data(&self) -> &TyData<TF> {
-    TF::lookup_ty(self)
+impl<I: Interner> Ty<I> {
+  fn data(&self) -> &TyData<I> {
+    I::lookup_ty(self)
   }
 }
 ```
 
 and
 
 ```rust,ignore
-impl<TF: TypeFamily> TyData<TF> {
-  fn intern(&self, tf: &TF) -> Ty<TF> {
-    Ty(tf.intern_ty(self))
+impl<I: Interner> TyData<I> {
+  fn intern(&self, I: &I) -> Ty<I> {
+    Ty(i.intern_ty(self))
   }
 }
 ```
@@ -63,6 +63,6 @@ Note that there is an assumption here that [`ty_data`] needs no
 context. This effectively constrains the [`InternedTy`] representation
 to be a `Box` or `&` type. To be more general, at the cost of some
 convenience, we could make that a method as well, so that one would
-invoke `ty.data(tf)` instead of just `ty.data()`. This would permit us
+invoke `ty.data(i)` instead of just `ty.data()`. This would permit us
 to use (for example) integers to represent interned types, which might
 be nice (e.g., to permit using generational indices).

book/src/types/operations/fold.md

@@ -3,7 +3,7 @@
 The [`Fold`] trait permits one to traverse a type or other term in the
 chalk-ir and make a copy of it, possibly making small substitutions or
 alterations along the way. Folding also allows copying a term from one
-type family to another.
+interner to another.
 
 [`Fold`]: http://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html
 
@@ -88,8 +88,8 @@ to require it. The derive for `Fold` is a bit cludgy and requires:
 
 * You must import `Fold` into scope.
 * The type you are deriving `Fold` on must have either:
-  * A type parameter that has a `TypeFamily` bound, like `TF: TypeFamily`
-  * A type parameter that has a `HasTypeFamily` bound, like `TF: HasTypeFamily`
-  * The `has_type_family(XXX)` attribute.
+  * A type parameter that has a `Interner` bound, like `I: Interner`
+  * A type parameter that has a `HasInterner` bound, like `I: HasInterner`
+  * The `has_interner(XXX)` attribute.
 
 

book/src/types/role_of_interner.md

@@ -0,0 +1,18 @@
+## The role of the `Interner`
+
+Most everything in the IR is parameterized by the [`Interner`] trait:
+
+[`Interner`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
+
+```rust,ignore
+trait Interner: Copy + Clone + Debug + Eq + Ord { 
+    ..
+}
+```
+
+We'll go over the details later, but for now it suffices to say that
+the interner is defined by the embedded and can be used to control
+(to a certain extent) the actual representation of types, goals, and
+other things in memory. For example, the `Interner` trait could be
+used to intern all the types, as rustc does, or it could be used to
+`Box` them instead, as the chalk testing harness currently does.

book/src/types/rust_lifetimes.md

@@ -1,8 +1,8 @@
 # Rust lifetimes
 
-Lifetimes are represented by the `Lifetime<TF>` and `LifetimeData<TF>`
+Lifetimes are represented by the `Lifetime<I>` and `LifetimeData<I>`
 types. As with types, the actual representation of a lifetime is
-defined by the associated type `TF::InternedLifetime`.
+defined by the associated type `I::InternedLifetime`.
 
 ### The `LifetimeData` variants
 

book/src/types/rust_types.md

@@ -4,9 +4,9 @@ Rust types are represented by the [`Ty`] and [`TyData`] types.
 You use [`Ty`] to represent "some Rust type". But to actually inspect
 what sort of type you have, you invoke the [`data`] method, which
 returns a [`TyData`]. As described earlier, the actual in-memory
-representation of types is controlled by the [`TypeFamily`] trait.
+representation of types is controlled by the [`Interner`] trait.
 
-[`TypeFamily`]: http://rust-lang.github.io/chalk/chalk_ir/family/trait.TypeFamily.html
+[`Interner`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
 [`Ty`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
 [`TyData`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyData.html
 [`data`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html#method.data
@@ -203,7 +203,7 @@ other type without any effect, and so forth.
 The rustc [`TyKind`] enum has a lot more variants than chalk. This
 section describes how the rustc types can be mapped to chalk
 types. The intention is that, at least when transitioning, rustc would
-implement the `TypeFamily` trait and would map from the [`TyKind`]
+implement the `Interner` trait and would map from the [`TyKind`]
 enum to chalk's `TyData` on the fly, when `data()` is invoked.
 
 [`TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html

book/src/types/rust_types/application_ty.md

@@ -19,7 +19,7 @@ more detail elsewhere. The point is that it represents, semantically,
 either the name of some user-defined type (like `Vec`) or builtin-types
 like `i32`. It may also represent types like "tuple of arity 2" (`(_,
 _)`) or "fixed-length array" `[_; _]`. Note that the precise set of
-these built-in types is defined by the `TypeFamily` and is unknown to
+these built-in types is defined by the `Interner` and is unknown to
 chalk-ir.
 
 [`TypeName`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TypeName.html