Greetings, everyone.
I've been trying out Rust recently and it's been a very pleasant
experience. I've been getting used to the type system and the memory
management semantics by implementing discriminator-based sorting, a
framework for linear-time sorting of a broad range of datatypes [1]. My
efforts so far can be found on github [2].
Discriminator-based parsing is based on a generic method that can be
implemented for whatever ordered key type K one needs to sort:
trait Disc<K,V> {
fn disc( 뇩 ~[(K,V)] ) -> ~[~[V]];
This function sorts a set of key/value pairs. It produces an ordered list
of sets; the list is produced in the order of the keys, and each set in the
list contains all the values that were associated with keys in an
equivalence class, although the keys themselves are stripped from the
output. This turns out to be a handy signature to use for recursive
sorting and to define sorting on new datatypes, but of course for external
clients there is a simpler ~[T] -> ~[T] interface.
The interesting part of implementing discriminators in Rust has been the
trait machinery needed to implement discriminators, because for each new
type one needs to implement Disc for a new K, but an arbitrary V. On the
other hand, V does not stay fixed during sorting; "pieces" of the key often
get shuffled off into V for sorting in subsequent passes, leading to
declarations like the following:
impl<'self,K:Clone,V,D:Disc<K,(vec::MoveIterator<K>,V)>>
Disc<'self[K],V> for VecDisc<D>
Here, VecDisc implements sorting for keys that are vectors of a cloneable
type K, and the VecDisc must contain a type D that implements sorting for
keys of type K and values that combine an iterator over K with a V -- so
that after sorting on early members of a vector, one can pick up the
remainder and continue lexicographic sorting.
By and large, Rust's type system has had everything I've needed for a
complex system like this, which is great, especially for such a new
language. I've run into a few compiler bugs along the way, and reported
them; the biggest showstopper for me was recently fixed, which let me
finish what I was writing, so I was happy about that. :)
The one thing I might want, if I were to play around with the design of
this library a little more, is something more like Haskell's type classes
without the OO flavor of traits. That is, the ability to write a generic
interface like Disc without a singular "receiver" type. By and large types
like VecDisc<D> above are useless placeholders. I have to say things like
VecDisc(IntDisc).disc(my_vectors), when I'd really rather just say
disc(my_vectors) and let the type system find the instantiation for vectors
of integers. I don't know of a good way to make this into
my_vectors.disc() because the type of my_vectors isn't an arbitrary type
parameter, it's always ~[(K,V)]. Of course its entirely possible I can do
what I need with Rust as-is, but if so I haven't found the right way yet.
The code as I've written it is just a piece of exploratory programming,
it's not really set up as a reusable library yet. There are no public
definitions, no documentation, no tests, several useful tools for building
new discriminators haven't been added, and I haven't benchmarked it at
all. I suspect, though technically O(n), discriminator-based sorting is
likely not the best for Rust users in general. It isn't in place, it does
lots of allocation, and it doesn't make good use of locality. I'll
probably run benchmarks in the near future to see how good it is or isn't,
and whether its log(n) speed-up pays for its constant factors or not.
Anyway, thanks very much to everyone developing Rust, this is a really
exciting language and I plan to keep playing around with it to see what's
new.
[1] Henglein, ICFP '08:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.154.2018
[2] http://github.com/carl-eastlund/rusty/blob/master/trait.rs
I've been trying out Rust recently and it's been a very pleasant
experience. I've been getting used to the type system and the memory
management semantics by implementing discriminator-based sorting, a
framework for linear-time sorting of a broad range of datatypes [1]. My
efforts so far can be found on github [2].
Discriminator-based parsing is based on a generic method that can be
implemented for whatever ordered key type K one needs to sort:
trait Disc<K,V> {
fn disc( 뇩 ~[(K,V)] ) -> ~[~[V]];
This function sorts a set of key/value pairs. It produces an ordered list
of sets; the list is produced in the order of the keys, and each set in the
list contains all the values that were associated with keys in an
equivalence class, although the keys themselves are stripped from the
output. This turns out to be a handy signature to use for recursive
sorting and to define sorting on new datatypes, but of course for external
clients there is a simpler ~[T] -> ~[T] interface.
The interesting part of implementing discriminators in Rust has been the
trait machinery needed to implement discriminators, because for each new
type one needs to implement Disc for a new K, but an arbitrary V. On the
other hand, V does not stay fixed during sorting; "pieces" of the key often
get shuffled off into V for sorting in subsequent passes, leading to
declarations like the following:
impl<'self,K:Clone,V,D:Disc<K,(vec::MoveIterator<K>,V)>>
Disc<'self[K],V> for VecDisc<D>
Here, VecDisc implements sorting for keys that are vectors of a cloneable
type K, and the VecDisc must contain a type D that implements sorting for
keys of type K and values that combine an iterator over K with a V -- so
that after sorting on early members of a vector, one can pick up the
remainder and continue lexicographic sorting.
By and large, Rust's type system has had everything I've needed for a
complex system like this, which is great, especially for such a new
language. I've run into a few compiler bugs along the way, and reported
them; the biggest showstopper for me was recently fixed, which let me
finish what I was writing, so I was happy about that. :)
The one thing I might want, if I were to play around with the design of
this library a little more, is something more like Haskell's type classes
without the OO flavor of traits. That is, the ability to write a generic
interface like Disc without a singular "receiver" type. By and large types
like VecDisc<D> above are useless placeholders. I have to say things like
VecDisc(IntDisc).disc(my_vectors), when I'd really rather just say
disc(my_vectors) and let the type system find the instantiation for vectors
of integers. I don't know of a good way to make this into
my_vectors.disc() because the type of my_vectors isn't an arbitrary type
parameter, it's always ~[(K,V)]. Of course its entirely possible I can do
what I need with Rust as-is, but if so I haven't found the right way yet.
The code as I've written it is just a piece of exploratory programming,
it's not really set up as a reusable library yet. There are no public
definitions, no documentation, no tests, several useful tools for building
new discriminators haven't been added, and I haven't benchmarked it at
all. I suspect, though technically O(n), discriminator-based sorting is
likely not the best for Rust users in general. It isn't in place, it does
lots of allocation, and it doesn't make good use of locality. I'll
probably run benchmarks in the near future to see how good it is or isn't,
and whether its log(n) speed-up pays for its constant factors or not.
Anyway, thanks very much to everyone developing Rust, this is a really
exciting language and I plan to keep playing around with it to see what's
new.
[1] Henglein, ICFP '08:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.154.2018
[2] http://github.com/carl-eastlund/rusty/blob/master/trait.rs