Johann Höchtl
Bytestrings and Lazy Bytestrings allow for fast and memory eficient string (well, bytestring) handling, yet a lot of libraries do not support them (yet)
WHat do you mean? A lot of libraries need to use String because it's easier to deal with and doesn't rely on knowing which encoding is being used. Bytestring is often nicer for IO, but for internal library stuff (e.g. parsing) it may still be easier to use String.
Given the incredibly inneficient memory representation of [Char] (16 bytes? per cell) I wonder wheather String should default to lazy batestring altogether instead of [Char].
Well, then all pattern matching, etc. fails. String and ByteStrings have their own separate places and uses.
The levenshtein distance as is on hackage uses e.g. String ([Char]) and as such is unneccessarily slow.
Have you ported a version to ByteString and demonstrated that it is noticeably faster? Are you sure that it isn't the fault of the algorithm being used? Do you know that people only care about the levenshtein distance of ByteStrings and not of normal Strings? (Disclaimer: I've never even looked at the package.) Providing a ByteString version as well might be a viable option; replacing the current one is quite likely not.
My question or discussion point: Why not depreciate [Char] altogether and favour of lazy Bytestrings?
I believe I've answered this above. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com