5 ms·
Having a bunch of string types is something people like to rag on Haskell for, but I think the reality is that strings are that complicated and most languages k
by wyager 5y ago
Having a bunch of string types is something people like to rag on Haskell for, but I think the reality is that strings are that complicated and most languages kind of sweep the complication under the rug, while Haskell chooses to accept it. Thankfully the practical downside is quite manageable; the most annoying thing you’ll occasionally have to do is call toStrict/fromStrict across library boundaries.
- assbuttbuttass 5y agoUsing [Char] as String was mistake. If Haskell used Data.Text everywhere strings would be fine
- throwaway81523 5y agoIf you mean a Text-like representation (basically ropes of codepoints) then sure, but Data.Text has a bunch of i/o including lazy i/o stirred in with it. Lazy i/o in particular is part of the still-lingering schizophrenia in Haskell about how to do i/o cleanly and safely. The current Streaming library is yet another try at that. I hadn't seen it before and it looks interesting, though I'll have to examine it more closely, and it still seems to be Iteratees deep down. I had the impression a few years ago that Pipes was the most cleanly designed of these schemes, but haven't been keeping track.
- wyager 5y agoStreaming is definitely the most cleanly designed today and also in my experience the fastest. It’s a shockingly simple design. Main downside is that it’s unidirectional, but I don’t think anyone really cares. Bidirectional pipes are tough to use.
- throwaway81523 5y agoThanks for this recommendation. I'll be sure to check it out in that case.
- whateveracct 5y agoTrue - going from Text to [Char] costs far less than the other direction all told. But [Char] is quite nice for certain uses.