<div dir="auto"><div>ByteString may not be the best way to represent a sequence of bytes, as it contributes to heap fragmentation by using pinned memory.<div dir="auto"><br></div><div dir="auto">Its primary use case should be FFI, and it's largely misused today.</div><div dir="auto"><br></div><div dir="auto">If we rename it, let's call it "PinnedBytes", and use the name "Bytes" for ShortByteString, ByteArray, or Array Word8</div><div dir="auto"><br></div><div dir="auto">All the best,</div><div dir="auto">Vlad</div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019, 12:25 Merijn Verstraaten <<a href="mailto:merijn@inconsistent.nl">merijn@inconsistent.nl</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, so I think there is a fairly wide consensus that the name ByteString is a pretty misleading historical naming mistake. On the other hand, I also realise bytestring is at the very core of the Haskell ecosystem and any breakage has to be avoided at all cost...<br>
<br>
So I was just wondering on IRC what (if any?) problems we'd run into if we released a "bytes" package that's just s/ByteString/Bytes of bytestring (Data.Bytes, Bytes type, etc) then turn bytestring into a hollow shell that just re-exports Data.Bytes as Data.ByteString, etc. and defines "type ByteString = Bytes".<br>
<br>
I realise there's no way we'll get rid of bytestring itself any time soon (if ever), but at least we could point new code and beginners at a less confusingly named type. Added bonus Bytes is considerably shorter to type!<br>
<br>
Cheers,<br>
Merijn<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>