That's not just about Haskell, it's C.S. in general. You're always going to make space and time tradeoffs. Funny how the same constraints appear in physics; I wonder if it is trying to tell us something... - nitrix On Jul 11, 2016 8:54 AM, "David Fox" wrote: On Sun, Jul 10, 2016 at 11:44 AM, KC wrote:

Is the #functional programming paradigm antithetical to efficient strings? #Haskell

​I can certainly see how it might seem so. Our main string representation​ uses about 10 times more memory than seems necessary, and is relatively fast, though probably not compared to C. Recently I spent some time looking into how to reduce this memory overhead, and I modified the pretty library (https://github.com/ddssff/pretty/tree/textdetails) so it could use any type that was an instance of ListLike and StringLike ( https://github.com/JohnLato/listlike). Then I tried the UnitLargeDoc test with several different data types. This just concatenates a list of ten million "Hello" strings. Using String this happens in about 5 seconds. Using strict or lazy Text it immediately blew the stack. When I increased the stack size to over 1GB it took minutes to complete. When I used the Data.Text.Lazy.Builder type instead it took about 30 seconds to complete. Results with utf8 encoded ByteStrings were siimilar. When I mentioned some of this, I was told "different data structures for different purposes", which sort of makes sense, but honestly if Haskell is a language where you have to sit down and choose a representation every time you want to build some text, I get a bit discouraged. So is functional programming antithetical to efficient strings? In theory maybe not, but I would love to see some hard evidence. </rant> _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.