I've been looking into ropes as an alternative to Data.Text, and I like what I see so much that I am now forced to ask this question.... Is there any case where Data.Text would be the better choice? Here are the points that lead me to this (correct me if I am wrong on any of these)- A single leaf node rope internally is (almost) the same thing as a Data.Text object. The overhead in a single node rope vs. text is minor, just a single bit flag to differentiate a branch or leaf. If you really want Data.Text, just use an unsplit rope. Complexity is universally equal or better in ropes- insert/delete (log(N) vs N), get by index (log(N)/N depending on depth of tree vs N). I've read that the success of ropes proved to be a mixed bag in c, because performance was harmed by thread safety code. However these concerns shouldn't matter in immutable Haskell. In fact, it would seem to me that because of this, Haskell and ropes are ideal for each other. Again, like in my previous similar questions, I am more interested in the abstract qualities of the structures, not the current situation (library usage, how hardened the code is, etc). If you rewrote the Haskell libraries tomorrow, would you substitute Data.Rope for Data.Text?

Reputation: 12060

Data.Text vs. Rope

I've been looking into ropes as an alternative to Data.Text, and I like what I see so much that I am now forced to ask this question.... Is there any case where Data.Text would be the better choice?

Here are the points that lead me to this (correct me if I am wrong on any of these)-

A single leaf node rope internally is (almost) the same thing as a Data.Text object. The overhead in a single node rope vs. text is minor, just a single bit flag to differentiate a branch or leaf. If you really want Data.Text, just use an unsplit rope.
Complexity is universally equal or better in ropes- insert/delete (log(N) vs N), get by index (log(N)/N depending on depth of tree vs N).
I've read that the success of ropes proved to be a mixed bag in c, because performance was harmed by thread safety code. However these concerns shouldn't matter in immutable Haskell. In fact, it would seem to me that because of this, Haskell and ropes are ideal for each other.

Again, like in my previous similar questions, I am more interested in the abstract qualities of the structures, not the current situation (library usage, how hardened the code is, etc). If you rewrote the Haskell libraries tomorrow, would you substitute Data.Rope for Data.Text?

Upvotes: 14

Answers (2)

misterbee

Reputation: 5172

A long time ago when I tried to use Rope, the author told me it wasn't really usable yet, it was just an experiment. One problem with Hackage is the difficulty of learning which package/versions are really production-ready.

Is the Rope as Unicode-compatible as Data.Text ?

Upvotes: 0

Philip JF

Reputation: 28539

The "finger tree of packed arrays" seems like a good representation choice, although I would worry about constant overhead. Some effort with aggressive stream fussion and some other optimizations for short strings might fix this, but Data.Rope lacks these features. Right now Data.Rope is not really a Data.Text replacmenet.

It mainly implements strings of bytes not strings of charachters--it replaces byteString not text. Unicode support is important.
Despite Edward's amazing-ness, Rope is not nearly as mature. It hasn't had any contributions in a year, and is rarely used.
Data.Text has a huge engineering effort behind it, is highly optimized, and is well known and well documented

Upvotes: 8

Data.Text vs. Rope

Answers (2)

Related Questions