A YiString is a FingerTree with cached column and line counts over chunks of Text.

See fromText.

Converts a Text into a YiString using defaultChunkSize-sized chunks for the underlying tree.

See fromText'.

This is like fromText but it allows the user to specify the chunk size to be used. Uses defaultChunkSize if the given size is <= 0.

See toText.

See toReverseText.

Note that it is actually ~4.5 times faster to use toReverseText and unpack the result than to convert to String and use reverse.

Consider whether you really need to use this!

Spits out the underlying string, reversed.

Note that this is actually slightly faster than manually unrolling the tree from the end, reverseing each chunk and concating, at least with -O2 which you really need to be using with Text anyway.

Checks if the given YiString is actually empty.

Creates an empty YiString.

Takes the first n given characters.

Drops the first n characters.

Length of the whole underlying string.

Amortized constant time.

Reverse the whole underlying string.

This involves reversing the order of the chunks as well as content of the chunks. We use a little optimisation here that re-uses the content of each chunk but this exposes a potential problem: after many transformations, our chunks size might become quite varied (but never more than the default size), perhaps we should periodically rechunk the tree to recover nice sizes?

Count the number of newlines in the underlying string. This is actually amortized constant time as we cache this information in the underlying tree.

This is like lines' but it does *not* preserve newlines.

Specifically, we just strip the newlines from the result of lines'.

This behaves slightly differently than the old split: the number of resulting strings here is equal to the number of newline characters in the underlying string. This is much more consistent than the old behaviour which blindly used ByteStrings split and stitched the result back together which was inconsistent with the rest of the interface which worked with number of newlines.

Splits the YiString into a list of YiString each containing a line.

Note that in old implementation this allowed an arbitrary character to split on. If you want to do that, manually convert toText and use splitOn to suit your needs. This case is optimised for newlines only which seems to have been the only use of the original function.

The newlines are preserved so this should hold:

'toText' . 'concat' . 'lines'' ≡ 'toText'

but the underlying structure might change: notably, chunks will most likely change sizes.

Joins up lines by a newline character. It does not leave a newline after the last line. If you want a more classical unlines behaviour, use map along with snoc.

Splits the string at given character position.

If position <= 0 then the left string is empty and the right string contains everything else.

If position >= length of the string then the left string contains everything and the right string is empty.

Implementation note: the way this works is by splitting the underlying finger at a closest chunk that goes *over* the given position (see split). This either results in a perfect split at which point we're done or more commonly, it leaves as few characters short and we need to take few characters from the first chunk of the right side of the split. We do precisely that.

All together, this split is only as expensive as underlying split, the cost of splitting a chunk into two, the cost of one cons and one cons of a chunk and lastly the cost of splitAt of the underlying Text. It turns out to be fairly fast all together.

Splits the underlying string before the given line number. Zero-indexed lines.

Splitting at line <= 0 gives you an empty string. Splitting at n > 0 gives you the first n lines.

Also see splitAtLine'.

Add a Char in front of a YiString.

We add the character to the front of the first chunk. This does mean that a lot of cons might result in an abnormally large first chunk so if you have to do that, consider using append instead..

Add a Char in the back of a YiString.

We add the character to the end of the last chunk. This does mean that a lot of snoc might result in an abnormally large last chunk so if you have to do that, consider using append instead..

Single character YiString. Consider whether it's worth creating this, maybe you can use cons or snoc instead?

Take the first character of the underlying string if possible.

Take the last character of the underlying string if possible.

Append two YiStrings.

We take the extra time to optimise this append for many small insertions. With naive append of the inner fingertree with ><, it is often the case that we end up with a large collection of tiny chunks. This function instead tries to join the underlying trees at outermost chunks up to defaultChunkSize which while slower, should improve memory usage.

I suspect that this pays for itself as we'd spend more time computing over all the little chunks than few large ones anyway.

Concat a list of YiStrings.

YiString specialised any.

Implementation note: this currently just does any by doing ‘TX.Text’ conversions upon consecutive chunks. We should be able to speed it up by running it in parallel over multiple chunks.

YiString specialised all.

See the implementation note for any.

The usual dropWhile optimised for YiStrings.

The usual takeWhile optimised for YiStrings.

As dropWhile but drops from the end instead.

Like takeWhile but takes from the end instead.

Concatenates the list of YiStrings after inserting the user-provided YiString between the elements.

Empty YiStrings are not ignored and will end up as strings of length 1. If you don't want this, it's up to you to pre-process the list. Just as with intersperse, it is up to the user to pre-process the list.

Intersperses the given character between the YiStrings. This is useful when you have a bunch of strings you just want to separate something with, comma or a dash. Note that it only inserts the character between the elements.

What's more, the result is a single YiString. You can easily achieve a version that blindly inserts elements to the back by mapping over the list instead of using this function.

You can think of it as a specialised version of intercalate. Note that what this does not do is intersperse characters into the underlying text, you should convert and use intersperse for that instead.

Filters the characters from the underlying string.

>>> filter (/= 'a') "bac"
"bc"

Maps the characters over the underlying string.

Splits the given YiString into a list of words, where spaces are determined by isSpace. No empty strings are in the result list.

Join given YiStrings with a space. Empty lines will be filtered out first.

Splits the YiString on characters matching the predicate, like split.

For splitting on newlines use lines or lines' instead.

Implementation note: GHC actually makes this naive implementation about as fast and in cases with lots of splits, faster, as a hand-rolled version on chunks with appends which is quite amazing in itself.

Takes every character but the last one: returns Nothing on empty string.

Takes the tail of the underlying string. If the string is empty to begin with, returns Nothing.

Returns a pair whose first element is the longest prefix (possibly empty) of t of elements that satisfy p, and whose second is the remainder of the string. See also span.

This implementation uses splitAt which actually is just as fast as hand-unrolling the tree. GHC sure is great!

Just like span but with the predicate negated.

Left fold.

Benchmarks show that folding is actually Pretty Damn Slow™: consider whether folding is really the best thing to use in your scenario.

Replicate the given YiString set number of times, concatenating the results. Also see replicateChar.

Replicate the given character set number of times and pack the result into a YiString.

>>> replicateChar 4 ' '
"    "

ConverterName is used to convey information about the underlying Converter used within the buffer to encode and decode text. It is mostly here due to the lack of Binary instance for Converter itself.

Returns the underlying string.

Reads file into the rope, also returning the ConverterName that was used for decoding. You should resupply this to writeFile if you're aiming to preserve the original encoding.

If we fail to guess the encoding used, error message is given instead.

It is up to the user to handle exceptions not directly related to character decoding.

Writes the given YiString to the given file, according to the Converter specified by ConverterName. You can obtain a ConverterName through readFile. If you have a Converter, use writeFileWithConverter instead.

If you don't care about the encoding used such as when creating a brand new file, you can use writeFileUsingText.

It's up to the user to handle exceptions.

Returns an error message if conversion failed, otherwise Nothing on success.

Write a YiString into the given file. This function uses writeFile to do the writing: if you have special needs for preserving encoding/decoding, use writeFile instead.

It's up to the user to handle exceptions.

As writeFile but using the provided Converter rather than creating one from a ConverterName.

It's up to the user to handle exceptions.

Helper function doing conversions of to and from underlying Text. You should aim to implement everything in terms of YiString instead.

Please note that this maps over each chunk so this can only be used with layout-agnostic functions. For example

>>> let t = 'fromString' "abc" <> 'fromString' "def"
>>> 'toString' $ 'withText' 'TX.reverse' t
"cbafed"

Probably doesn't do what you wanted, but toUpper would. Specifically, for any f : Text → Text, withText will only do the ‘expected’ thing iff

f x <> f y ≡ f (x <> y)

which should look very familiar.

Maps over each chunk which means this function is UNSAFE! If you use this with functions which don't preserve Size, that is the chunk length and number of newlines, things will break really, really badly. You should not need to use this.

Also see unsafeFmap