Strictness and laziness ergonomics

[Kleidukos]

The fact that we have both lazy and strict Text 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.Text.Lazy was imported.

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

import qualified Data.Text.Lazy as LT

-- | Type synonym for 'Data.Text.Lazy.Text'.
type LText = LT.Text

What it does

• Allows the codebase contributor to specify with more clarity to other contributors that the Text 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/bytestring repo: haskell/bytestring#375

[kozross]

In my experience, type synonyms aren't that great. They're expanded sometimes by GHC (never consistently), which means you can easily end up with confusing messaging from the compiler. This basically forces you to keep this information in your head at all times.

I certainly do agree that there needs to be a much stronger distinction between the two Text flavours. I just don't think this is a good way to do this.

[Kleidukos]

@kozross As I can understand this argument for Servant's type aliases, which are pretty much indecipherable without good knowledge of the library's inner working, I have a hard time imagining being confused by Data.Text.Lazy.Text vs. LText.
The target audience is pretty much aware that they are using this type alias to be more explicit about the lazy nature of the type, and it doesn't hide complex type machinery behind.

[parsonsmatt]

One irritating thing that i see a lot in Haddock is something like:

toLazyText :: Foo -> Text
toStrictText :: Foo -> Text

An LText alias would be much easier to follow and disambiguate in the documentation, which would be great not just for text but also any library that depends on it.

One way to cut the Gordian knot here is to deprecate Lazy entirely and have users defer to streaming abstractions for these use cases. I've never been a fan of that dichotomy, and it mostly seems useful for lazy IO, which I'm also not a huge fan of.

[Kleidukos]

We should push for a broader adoption of proper streaming abstractions instead of Lazy Text for IO.
@parsonsmatt: Would you be open to the idea of publishing an article / tutorial on how to better replace lazy text / bytestring with, idk pipes for example?

[parsonsmatt]

If we decide that deprecating the Lazy stuff is worthwhile then I'd be happy to write for the cause.

[Kleidukos]

To be quite honest, I don't think it will ever be considered unless we are certain that the ecosystem is ready for the migration (which means pedagogical materials for learners, adoption by popular libraries and projects, etc).
And this is a cultural change that I see happening over the course of several years.

[kozross]

I agree with @parsonsmatt - lazy Text should go. I would also be quite happy to assist with the necessary writing.

[Bodigrim]

No one forces people to use lazy Text, if they do not want to. As soon as the majority of ecosystem is convinced to use something else and has switched, we will be in a good position to discuss its deprecation.

I understand why people damn lazy I/O. But it is only a small facet of lazy Text. What would happen with Builder, for example?

Deprecating Data.Text.Lazy.IO could be a more actionable item, if someone wishes it to raise as a separate issue.

[parsonsmatt]

I talked to Snoyman about Builder and he suggested that it might be worth deprecating, as well. The gist of it is that a Builder type is almost always used for I/O, at which point you should be using a ByteString builder and not a Text builder anyway.

In any case, deprecating any part of text's API is a bit out of scope for this discussion - my apologies for raising it at all 😅

[kozross]

Not to mention that (for ByteString at least), there's faster Builder implementations that don't rely on the corresponding lazy type. This is quite likely true for Text as well. It's not even worth it for builders IMHO.

[Bodigrim]

I must reiterate: no one forces people to use lazy Text or Builder. Feel free to promote alternatives and convince others to switch. Simply breaking thousands of packages is not a sensible option IMO. Users do not normally have an option to stick to an older text, it is a boot package.

Sticking to a topic, I think it is a good idea. To avoid undesirable expansion of type synonyms, we can actually do things vice versa, defining data LazyText = ... and type Text = LazyText.

[kozross]

@Bodigrim I completely disagree. Try using a library which uses lazy Text - then you have to interact with it, whether you like it or not. If that's not 'forced', I dunno what is - especially if the library isn't really about text as-such.

But I agree, this is off-topic, so I'll stop.

[kozross]

@Kleidukos I'm not sure such a community migration will ever happen unless driven aggressively by us. Alternatives and better solutions, both semantically and performance-wise, to lazy Text, for both streaming and building, have been around for nine years now, and more get added at least every couple of months.