New abstract type section

Author: soareschen

blog/2026-03-30-incoherent-rust-today.md

@@ -1039,7 +1039,7 @@ There is also an important way in which CGP diverges from traditional algebraic
 These observations point toward a better fit in the [**coeffects**](https://tomasp.net/coeffects/) framework, which studies how contextual requirements flow through a computation rather than how computational effects flow out of it. Where effects describe what a computation produces or performs, coeffects describe what a computation requires from its environment. The generic context in CGP serves precisely this role: it carries the implementation choices and capabilities that a computation depends on, and those dependencies are resolved all at once when a concrete context is defined. A full introduction to coeffects is beyond the scope of this blog post, but the connection is worth noting for readers interested in the theoretical foundations of what CGP is doing.
 
 
-### 0-arity traits
+### Zero-arity traits
 
 CGP provides a desugaring of incoherent Rust traits into CGP traits that have an additional `Context` type, with the original `Self` type moved to an explicit generic parameter. For example, given the incoherent trait:
 
@@ -1084,7 +1084,7 @@ With incoherence and capabilities, a useful design pattern that emerges is the u
 ```rust title="Incoherent Rust"
 impl GreetHello = Greet for !
 with
-    name: String,
+    name: &String,
 {
     fn greet() {
         println!("Hello, {}!", name);
@@ -1099,13 +1099,281 @@ With CGP, since the context type is explicit, zero-arity incoherent traits becom
 impl GreetImpl {
     fn greet(
         &self,
-        #[implicit] name: String,
+        #[implicit] name: &String,
     ) {
         println!("Hello, {}!", name);
     }
 }
 ```
 
+### Abstract types
+
+There is an interesting implication of using associated types within zero-arity traits, which is that it introduces a new concepts that I'd call **abstract types**. For example, we can introduce an abstract type called `Name` with the following trait:
+
+
+```rust title="CGP"
+#[cgp_type]
+pub trait HasNameType {
+    type Name: Display;
+}
+```
+
+
+The interesting property about abstract types is that the type does not depend on any specific type, but rather is chosen by the ambient context. For example, we can modify the `GreetHello` implementation earlier to use the `Name` abstract type:
+
+
+```rust title="CGP"
+#[cgp_impl(new GreetHello)]
+#[use_type(HasNameType::Name)]
+impl GreetImpl {
+    fn greet(
+        &self,
+        #[implicit] name: &Name,
+    ) {
+        println!("Hello, {}!", name);
+    }
+}
+```
+
+In this updated implementation, the hardcoded `String` type for the `name` parameter is now replaced by the abstract type `HasNameType::Name`. This allows the implementation to be reused by different name types that may be chosen by the context.
+
+For example, we can now define a type like `FullName`, and use it as the custom `Name` type:
+
+```rust
+pub struct FullName {
+    pub first_name: String,
+    pub last_name: String,
+}
+
+impl Display for FullName {
+    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
+        write!(f, "{} {}", self.first_name, self.last_name)
+    }
+}
+
+pub struct Context {
+    pub name: FullName,
+}
+
+delegate_components! {
+    Context {
+        NameTypeProviderComponent:
+            UseType<FullName>,
+        GreeterComponent:
+            GreetHello,
+    }
+}
+
+fn main() {
+    let context = Context {
+        name: FullName {
+            first_name: "John".to_owned(),
+            last_name: "Smith".to_owned(),
+        },
+    };
+
+    // Prints "Hello, John Smith!"
+    context.greet();
+}
+```
+
+#### Abstract types in Incoherent Rust
+
+Let's take a look at how abstract types would look like if we introduce it in Incoherent Rust. First, we would define `HasNameType` as a zero-arity trait as follows:
+
+```rust title="Incoherent Rust"
+pub trait HasNameType for ! {
+    type Name: Display;
+}
+```
+
+Since abstract types are built on top of zero-arity traits, we would need to introduce new syntax to use the abstract type:
+
+```rust title="Incoherent Rust"
+impl GreetHello = Greet for !
+where
+    impl NameType: HasNameType,
+with
+    name: &NameType::Name,
+{
+    fn greet() {
+        println!("Hello, {}!", name);
+    }
+}
+```
+
+Here, we require the context to provide an implementation of `HasNameType`, and bind it to the local identifier `NameType`. We then refer to the abstract type using `NameType::Name` when using it as the type for the `name` capability.
+
+Now that the implementation is ready, we can setup the wiring and call `GreetHello::greet()` by writing something like follows:
+
+```rust title="Incoherent Rust"
+impl UseFullNameType = HasNameType {
+    type Name = FullName;
+}
+
+fn main() {
+    with
+        UseFullNameType,
+        name = FullName {
+            first_name: "John".to_owned(),
+            last_name: "Smith".to_owned(),
+        }
+    {
+        // Prints "Hello, John Smith!"
+        GreetHello::greet();
+    }
+}
+```
+
+Here, we choose `UseFullNameType` as the incoherent implementation for `HasNameType`, and then bind the capability `name` with a `FullName` value. When `GreetHello` is called, both the type implementation and the name value are provided through the trait system, and the greeting is printed.
+
+#### Using abstract types across incoherent traits
+
+With the earlier abstract `Name` type, it might not be clear what is the difference of defining the associated type through a zero-arity trait, as compared to just implementing everything using the normal unary traits. We will expand on it in this section to see how zero-arity traits provide uniform access across multiple unary trait implementations that have *different* `Self` types.
+
+Suppose that we want to implement a generic `touch` function that gets the current system time, and then modify any type that contains the `last_modified` field. We may first define a trait like follows:
+
+```rust
+use std::time::SystemTime;
+
+pub trait UpdateLastModified {
+    fn update_last_modified(
+        &mut self,
+        time: SystemTime,
+    );
+}
+```
+
+The `UpdateLastModified` trait is straightforward: It accepts a `&mut self` and a [`SystemTime`](https://doc.rust-lang.org/stable/std/time/struct.SystemTime.html), and updates the time field in `self` to the given time. With it, we can define the `touch` function simply as follows:
+
+```rust
+pub fn touch<T: UpdateLastModified>(value: &mut T) {
+    let time = SystemTime::now();
+    value.update_last_modified(time);
+}
+```
+
+While the `touch` function works, it introduces some tight coupling with the a specific concrete implementation of time. We may want to make use of a *generic* `Time` type that can be instantiated to different concrete time types, such as [`std::time::Instant`](https://doc.rust-lang.org/std/time/struct.Instant.html), [`time::UtcDatetime`](https://docs.rs/time/latest/time/struct.UtcDateTime.html), or [`chrono::DateTime`](https://docs.rs/chrono/latest/chrono/struct.DateTime.html).
+
+A naive attempt would be to add a generic parameter `Time` as follows:
+
+```rust
+pub trait UpdateLastModified<Time> {
+    fn update_last_modified(
+        &mut self,
+        time: Time,
+    );
+}
+
+pub fn touch<Time, T: UpdateLastModified<Time>>(
+    value: &mut T,
+)
+where
+    Time: From<SystemTime>,
+{
+    let time = SystemTime::now();
+    value.update_last_modified(time);
+}
+```
+
+Now the `UpdateLastModified` trait is parameterized by a generic `Time` type, and the `touch` function also needs to accept `Time` as an extra generic parameter. Furthermore, even though our code is generic over the `Time` type, it still uses `SystemTime::now()` to obtain the current time, and require a `From` conversion from `SystemTime` to the generic `Time`.
+
+An alternative is that we can make `Time` an associated type. Such as:
+
+```rust
+pub CurrentTime {
+    fn current_time() -> Self;
+}
+
+pub trait UpdateLastModified {
+    type Time: CurrentTime;
+
+    fn update_last_modified(
+        &self,
+        time: Self::Time,
+    );
+}
+
+pub fn touch<T: UpdateLastModified>(value: &mut T) {
+    let time = T::Time::current_time();
+
+    value.update_last_modified(time);
+}
+```
+
+But the definition don't exactly sit right. First, there is now a different `Time` type for every type `T` that implements `UpdateLastModified`. Furthermore, the trait `CurrentTime` is tightly coupled with the concrete `Time` definition. This makes it challenging to swap a mock implementation to be used for testing.
+
+With zero-arity traits and Incoherent Rust, we can instead write something like the following:
+
+```rust
+// An abstract type trait is a zero-arity trait with an associated type
+pub trait HasTimeType for ! {
+    type Time;
+}
+
+// The current time is provided by with ambient context using a zero-arity trait
+pub trait CurrentTime for !
+where
+    impl TimeImpl: HasTimeType,
+{
+    fn current_time() -> TimeImpl::Time
+}
+
+// The `Time` type does not depend on `Self`
+pub trait UpdateLastModified
+where
+    impl TimeImpl: HasTimeType,
+{
+    fn update_last_modified(
+        &mut self,
+        time: TimeImpl::Time,
+    );
+}
+
+// The time type and current time implementations are not bound to `T`
+pub incoherent fn touch<T: UpdateLastModified>(
+    value: &mut T,
+)
+where
+    impl TimeImpl: HasTimeType + CurrentTime,
+{
+    let time = TimeImpl::current_time();
+    value.update_last_modified(time);
+}
+```
+
+As we can see, zero-arity traits allows us to define `Self`-less implementations that are not bound to any generic parameters. This also allows us to be reuse the same zero-arity trait implementations across multiple generic types. For example, when there are two generic types `Folder` and `File`, we can be confident that both of them would reuse the same time implementations within the same call.
+
+The same zero-trait example above can be defined in CGP today as:
+
+```rust
+#[cgp_type]
+pub trait HasTimeType {
+    type Time;
+}
+
+#[cgp_component(CurrentTimeImpl)]
+pub trait CurrentTime: HasTimeType {
+    fn current_time(&self) -> Self::Time;
+}
+
+#[cgp_component(UpdateLastModifiedImpl)]
+#[use_type(HasTimeType::Time)]
+pub trait UpdateLastModified<T> {
+    fn update_last_modified(value: &mut T, time: Time);
+}
+
+#[cgp_fn]
+#[uses(CurrentTime)]
+pub fn touch<T>(&self, value: &mut T) {
+    let time = self.current_time();
+    value.update_last_modified(time);
+}
+```
+
+As we can see, CGP converts zero arity traits into single-arity traits that are bound to the generic context. On the other hand, the original `Self` type in Incoherent Rust is shifted to become explicit generic parameters `T`. With this, it becomes clear that traits like `HasTimeType` and `CurrentTime` are bound to the context instead of the generic `T` type. This example should make it clear the benefits of zero-arity traits and abstract types that are bound to the ambient context instead of the value types.
+
+
 ### Contexts as explicit types
 
 Another key distinction is that CGP contexts are explicit Rust types. This means we can use the context as a regular Rust type inside a larger context. Incoherent Rust, on the other hand, assumes an implicit ambient context that propagates named impls from callers to callees. This makes it more restrictive to use Incoherent Rust when implementing traits for concrete types.