Do not use lazy `ByteString`s for variable names about plutus

[vmchale]

@mchakravarty is this pertinent given the use of Uniques?

Is there any evidence of the above issues occurring when performing profiling or benchmarking?

[effectfully]

is this pertinent given the use of Uniques?

How are uniques related?

Is there any evidence of the above issues occurring when performing profiling or benchmarking?

1. The fact that there is no evidence at hand does not mean we can ignore a well-known problem and an advice from someone who implemented the library:

I've been wanting to switch to unpinned for ByteString for years, but it's a lot of work. It'd mean fixing up lots of other libs that use ByteString internals and it also requires a solution for the mmap'd ByteString use case (which does have solutions but it's still more work and may need some RTS extensions to be able to have an mmaped ByteArray# that unmaps when it's collected).

As a workaround I often recommend people use ShortByteString, which is part of the bytestring package and uses unpinned memory.

2. Regardless of performance issues, there is a huge semantic issue: it's just plain nonsense to use lazy sequences of bytes for short human-readable text. At the very least it should be strict Text which would also save us some pain related to handling of variable names, like this for example:

language-plutus-core/generators/Language/PlutusCore/Generators/Internal/Entity.hs:import           Data.Text.Encoding                                      (encodeUtf8)
language-plutus-core/generators/Language/PlutusCore/Generators/Internal/Entity.hs:    Name ann (name <> BSL.fromStrict (encodeUtf8 . prettyText $ unUnique uniq)) uniq
language-plutus-core/src/Language/PlutusCore/Quote.hs:freshNameText ann = freshName ann . BSL.fromStrict . Text.encodeUtf8

[effectfully]

A Text value uses unpinned memory - meaning that it is controlled by the GHC garbage collector and can be moved around at will. -- string-types

So we can go with just strict Text for now and try ShortText later in a benchmark-driven way if we have time for that.

[vmchale]

A Text value uses unpinned memory - meaning that it is controlled by the GHC garbage collector and can be moved around at will. -- string-types

That's not relevant in our case.

[effectfully]

That's not relevant in our case.

Why not? Pinned memory is leaky, unpinned memory is not. Seems relevant to me.