Hello,
While Patrick's advice to avoid @ is good in general, in this case I
think it does not apply. Persistent or purely functional data
structures basically must use @ so that they can share pointers into
their internal nodes. I do hope that when Rust's libraries become more
mature we wil
On Sat, Dec 15, 2012 at 7:15 PM, Patrick Walton wrote:
> On 12/15/12 4:38 PM, Steve Jenson wrote:
>
>> I could use advice here. Is it possible for me to write a single trait
>> that can be used by both users that want to use managed boxes and people
>> who wish otherwise? IOW, what is the best wa
On 12-12-18 04:56 PM, Steve Jenson wrote:
> That's a mutable LLRB tree whereas mine is immutable.
Ah. Good point.
> Since the language provides optional mutability, is it a goal to have
> both pure functional and mutable versions of common data structures and
> traits?
In some sense. Specifical
On Mon, Dec 17, 2012 at 11:28 AM, Graydon Hoare wrote:
>
> Nice! The only things I'd ask are:
>
> - I can't tell at a glance (sorry, RB-trees are always very subtle)
> whether this is an LLRB. If not, could you make it so? It's likely
> just a simplification to a couple of the functions
On Mon, Dec 17, 2012 at 11:46 AM, Graydon Hoare wrote:
> On 12-12-17 11:28 AM, Graydon Hoare wrote:
> > On 12-12-14 03:51 PM, Steve Jenson wrote:
> >> I recently ported Matt Might's Scala port of Okasaki's purely functional
> >> red-black tree to Rust and am looking for some feedback.
> >>
> >> h
Thanks, I started with this definition and implemented BaseIter for my
RBTree.
https://github.com/stevej/rustled/commit/85cf4340eb1c0b985e27a48fe2603e6b75ffcb45
size_hint returns None as I'm not tracking size. I think that's ok? It's
hard to tell from the BaseIter documentation.
On Mon, Dec 17,
On Sat, Dec 15, 2012 at 7:02 PM, Nathan wrote:
> > Also, traverse should probably belong in its own trait.
> >
>
> It seems like traversal over keys *and* values is quite useful,
> because it's common for applications to need both, and doing a
> separate lookup when a traversal is already "close
Is it important for `traverse` to pass along an option type? Is it
important to inform end users that a key has been deleted? Or is that
implementation specific? If so, I suggest rewriting `traverse` to something
like this (assuming this actually works):
impl RBMap: iter::BaseIter<(&K, &V)> {
On 12-12-17 11:28 AM, Graydon Hoare wrote:
> On 12-12-14 03:51 PM, Steve Jenson wrote:
>> I recently ported Matt Might's Scala port of Okasaki's purely functional
>> red-black tree to Rust and am looking for some feedback.
>>
>> https://github.com/stevej/rustled/blob/master/red_black_tree.rs
>>
>>
On 12-12-14 03:51 PM, Steve Jenson wrote:
> I recently ported Matt Might's Scala port of Okasaki's purely functional
> red-black tree to Rust and am looking for some feedback.
>
> https://github.com/stevej/rustled/blob/master/red_black_tree.rs
>
> I've written this for 0.4 and will update it with
On 12/15/12 7:15 PM, Patrick Walton wrote:
However, if you modify the algorithm to use unique pointers throughout,
then your methods like get() can probably return a borrowed pointer
instead.
To add: For anyone interested in making data structures that don't use
the garbage collector, look at
On 12/15/12 4:38 PM, Steve Jenson wrote:
I could use advice here. Is it possible for me to write a single trait
that can be used by both users that want to use managed boxes and people
who wish otherwise? IOW, what is the best way to abstract away the @sign
in this trait?
It depends on how you
On Sat, Dec 15, 2012 at 4:45 PM, Steve Jenson wrote:
>
>
>
> On Sat, Dec 15, 2012 at 8:58 AM, Benjamin Striegel
> wrote:
>>
>> Would this trait:
>>
>> pub trait Map {
>> pure fn get(k: K) -> @Option;
>> pure fn put(k: K, v: V) -> self;
>> pure fn delete(k: K) -> self;
>>
On Sat, Dec 15, 2012 at 8:58 AM, Benjamin Striegel
wrote:
> Would this trait:
>
> pub trait Map {
> pure fn get(k: K) -> @Option;
> pure fn put(k: K, v: V) -> self;
> pure fn delete(k: K) -> self;
> pure fn traverse(f: fn((&K), (@Option)));
> }
>
> be something that
On Sat, Dec 15, 2012 at 11:46 AM, Patrick Walton wrote:
> On 12/15/12 8:58 AM, Benjamin Striegel wrote:
>
>> Would this trait:
>>
>> pub trait Map {
>>pure fn get(k: K) -> @Option;
>>pure fn put(k: K, v: V) -> self;
>>pure fn delete(k: K) -> self;
>>pure fn tra
On 12/15/12 8:58 AM, Benjamin Striegel wrote:
Would this trait:
pub trait Map {
pure fn get(k: K) -> @Option;
pure fn put(k: K, v: V) -> self;
pure fn delete(k: K) -> self;
pure fn traverse(f: fn((&K), (@Option)));
}
be something that ought to live somewher
Would this trait:
pub trait Map {
pure fn get(k: K) -> @Option;
pure fn put(k: K, v: V) -> self;
pure fn delete(k: K) -> self;
pure fn traverse(f: fn((&K), (@Option)));
}
be something that ought to live somewhere in the standard library?
I also see that you have a
17 matches
Mail list logo
