On Fri, Nov 15, 2013 at 05:05:28PM +0100, Gábor Lehel wrote:
> The next few are going to be about higher- (or just different-) kinded
> generics. To avoid confusion, I'm going to use "built-in trait" to mean
> things like `Freeze` and `Send`, and "kind" to mean what it does everywhere
> else in the non-Rustic world.

OK, I read a bit more. I've been working on a blog post about "HKR"
(higher-kinded Rust) and you've been elaborating on some of the same
themes as I was thinking about (naturally enough). All makes sense.

> One question with regards to higher-kinded traits is what to do about
> methods and `self`. What syntax to use? Does it even make sense? For
> syntax, I see two possibilities (snipping from the `fmap` signature):
>  - `self: &Self<A>`
>  - `&self<A>`

I was leaning towards the former, but the latter does make sense too
and would help to guide users into a more limited set of available
options, which might be helpful.

>     trait Foldable for type<type> Self {
>         fn fold<T>(&self<T>, init: &T, folder: |&T, &T| -> T) -> T;
>     }
> 
> Then `&Foldable<int>` is a trait object hiding any foldable container of
> ints (for example `~[int]`).

In the absence of an erased keyword, I think that higher-kinded traits
and objects are simply incompatible. The situation is not as simple as
you made it out, as the trait may itself have generic parameters of
higher-kind. I think the thing to do, if you wanted an object type,
would be to have an "adapter" trait:

>     trait Foldable1<T> {
>         fn fold(&self, init: &T, folder: |&T, &T| -> T) -> T;
>     }
>
>     impl<T:Foldable,U> Foldable1<U> for T<U> {
>         fn fold(&self, init: &T, folder: |&T, &T| -> T) -> T {
>             Foldable::fold(self, init, folder)
>         }
>     }

> The other is the potential to abstract over traits. GHC does this with the
> `ConstraintKinds` extension. (According to people who have implemented
> Haskell compilers, it's actually easier to implement it than not to![1]
> Which is pretty crazy.)

I'm not sure this would be true for Rust, but perhaps.

> There's two further issues that higher-kinded generics raise...

This is as far as I got in this round. More later. :)


Niko
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to