Strictness and laziness ergonomics

[Kleidukos]

The fact that we have both lazy and strict ByteString types without any marker outside of their namespace is rather unfortunate.
In pretty big codebases or modules, it's also easy to forget that Data.ByteString.Lazy was imported.

This is why, inspired by Kowainik's work, I would like to introduce the following type alias:

import qualified Data.ByteString.Lazy as LB

-- | Type synonym for 'Data.ByteString.Lazy.ByteString'.
type LByteString = LB.ByteString

What it does

• Allows the codebase contributor to specify with more clarity to other contributors that the ByteString flavour that is used is lazy, and reducing the cognitive overhead of said contributors. Very useful in codebase operated by multiple people over a long time with new onboardings.

What it does not

• Provides a magic tool that solves every problem under the sun
• Forces you to use it
• Kills your kitten

A similar ticket was opened in the haskell/text repo: haskell/text#317

[sjakobi]

I like this idea!

How about calling it LazyByteString though?! 3 more characters but no more uncertainty what that L might mean.

[sjakobi]

I think adding a StrictByteString type synonym might make sense too.

[Kleidukos]

@sjakobi I initially went with the alias used by relude's Relude.String.Conversion. If you feel like LazyByteString is what you want, I'm not going to argue. :)

The original names were good enough that I didn't judge necessary to change them, and if the maintainers of text keep the LText alias, they will be consistent with one another (and God knows consistency is important in a language)

[Bodigrim]

Just to be clear about credits: I believe that relude inherited LByteString from protolude, and this type synonym is a folklore, appearing through many alternative preludes: https://www.stackage.org/lts-17.5/hoogle?q=LByteString

LazyByteString is also popular, but less so: https://www.stackage.org/lts-17.5/hoogle?q=LazyByteString

StrictByteString is not very well attested, https://www.stackage.org/lts-17.5/hoogle?q=StrictByteString

[Kleidukos]

Yes indeed, thank you very much @Bodigrim!

[sjakobi]

I don't see much advantage to re-using a name that is already popular. That would only increase the likelihood of name clashes.

If people prefer abbreviations, we might as well go with LBS.

My vote is for LazyByteString and StrictByteString.

[kindaro]

We can also call the strict one ByteArray and the lazy one ByteStream. Or something like that. Advertise the difference of purpose.

[sjakobi]

We can also call the strict one ByteArray and the lazy one ByteStream.

These names are admittedly clearer. But I think they are too far a departure from the existing module naming. People would be unlikely to make the connection with the bytestring package.

[Bodigrim]

I'm in favor of LazyByteString.

I'm not sure that StrictByteString is well-justified: there is no Data.ByteString.Strict module (on contrary to hierarchy used in containers and unordered-containers). But I do not hold a strong opinion, an additional type synonym is not particularly harmful.

[sjakobi]

I'm not sure that StrictByteString is well-justified: there is no Data.ByteString.Strict module (on contrary to hierarchy used in containers and unordered-containers).

So my motivation is that even after the introduction of LazyByteString, when you encounter a ByteString, it's not immediately obvious whether this is a strict ByteString or a lazy ByteString that simply doesn't use the new type synonym yet. You can avoid this uncertainty by using the StrictByteString synonym.

[Bodigrim]

I see, makes sense.

@Kleidukos a PR, adding LazyByteString and StrictByteString type synonyms, would be appreciated.

[Kleidukos]

Alright, it's on!