GDP Rust Planning 2018-09-05

Tags:
By Max Woerner Chase

In this post:


So, last weekend, I started working on attempting to port Ghosts of Departed Proofs from Haskell to Rust. It appears that, by now, I've got the core mostly working, and I'm focusing on proving this out by trying to implement Ghosts functionality for sorted Vec and Iterator.

So far as that, my plan there is to implement functionality for every kind of stdlib iterator that makes sense in the context of "preserving a sorted invariant", then create a Merged iterator struct. Thinking over how I'd implement such a thing earlier, I concluded that the implementation would actually be kind of obnoxious, so I'll content myself with just laying the groundwork for now.

In terms of the quality of the code right now, there are a few issues and open questions:

In terms of stdlib code to write special handling for:

There are also a bunch of traits. The way I'm doing things currently, I can't have blanket impls, but I might change that. The basic issue is that, until I changed it literally as I was writing this, I was using a single structure for every role in this code, which turns out not to work all that well in terms of blanket impls. The impls stop conflicting, though, if I have different container types for different kinds of object, so that turns out to be okay. Now, I can't do a blanket implementation of FromIterator because not all containers preserve insertion order, so that's going to be a piecemeal kind of thing.

I might also want to change the way I do products of names; I'll have to see if there are any disadvantages to using simple tuples.

I mentioned earlier that the implementation of Merged seemed obnoxious. Basically, it's a pair of peekable, potentially double-ended, fused iterators, along with a function. If either iterator is exhausted, it must be discarded and not consulted again.

I just realized that Enumerate, Rev, and Zip have some more issues: Enumerate and Zip need to have a corresponding set of function combinators, as does Rev.

The stuff I feel like doing goes roughly in order of:

This is probably not entirely honest, in that I've got a good idea of how I want Merged to look, but I'd rather have more experience with the code before I commit to it.

I think I'll break down the tasks for the two middle posts in this week thus:


Next time, EDIT: WHOOPS I DIDN'T FILL THIS IN FOR TWO DAYS I look into improving the documentation, and then the overall API.