Open cdornan opened 5 years ago
I strongly advise against the text Builder
in general, and I don't really understand its use cases. It has to be converted to a pinned memory representation to perform any I/O, and I advise against keeping lazy Text
values around as well. Can you clarify what kind of use case you're looking at?
My preference would be to build up Utf8Builder
's interface more and recommend that for building up textual values.
@snoyberg I get it — everyone should migrate away from text Builder
. My point is that many folks are right now using packages like fmt
(which alone has a similar number of downloads as rio
) which are based on text
Builder
. I would much prefer to have decent fmt-like tools that generated Utf8Builder
but that isn't the world we are living in and Utf8Builder
isn't even available apart from rio
if anyone were minded to attempt such an enterprise.
(A related question, is anyone thinking about floating RIO.Prelude.Display
into a separate package so it can acquire its own ecosystem.)
I am just making the case for unbundling the issues and reducing the barriers to entry. I can work around it; I just like rio
and would like to see get as much traction as possible. (To that end unbundling RIO.Prelude.Display
is probably the more critical issue.)
(I have my answer — please close the issue, but I am curious about the Display
roadmap.)
One potential workaround here would be to expose type TextBuilder = Data.Text.Builder.Builder
from RIO
, similar to how we have LByteString
and LText
(even though I prefer avoiding both).
I'm not such a huge fan of spinning off Utf8Builder
into its own package; I've spent enough time splitting up my packages and incurring a maintenance cost that I don't want to go down that route.
As for future plans for Display
: I don't have concrete ones right now, especially as it's currently doing the bare minimum I need from it. I'd love to work with someone who has solid goals for a more full-featured text display approach they'd like to see.
I really like the TextBuilder
idea!
Being a pragmatist I have absolutely no answer to your point about the maintenance burden except, of course, that a trustworthy person could be found to take on the work of closely-supervised maintenance.
It would be truly marvellous if the community could coordinate around a Utf8Builder
type and Display
class (something that should have been in Haskell 1.0 IMHO; I have railed for many years against its absence and the related abuses of show
[e.g., UTCTime
]).
A related question, is anyone thinking about floating RIO.Prelude.Display into a separate package so it can acquire its own ecosystem.
I must admit, I've also thought this might be a good idea. More extensively:
rio-monad display
____|____ |
| | logfunc
rio-orphans |_______|
|
rio
On the other hand, I absolutely sympathize with the pain of juggling separate packages. Especially considering that RIO.Prelude.Logger
is already built with other pieces of RIO.Prelude
(though really, that's the lowest priority for splitting off).
Yes, logging was the other item on my list but only to mention it and see what the issues were.
I'm willing to consider the idea, especially if people are stepping up to the plate to take on some of the maintenance. But it's definitely not top of my priority list.
With text
moving to UTF-8 internals and text-display entering the spotlight, would it be the time to delegate the Display
class and related functions?
No, neither of those changes affect the motivations described here.
What would it take to implement "a more full-featured text display approach" that is available outside rio
?
I’m personally not interested in solving that problem. We have a solution in rio, and I’m not actively pursuing ways to split up my libraries further.
I know the rio is self-sufficient. It's just getting annoying to mix and match almost identical similarly named things.
I'm with @cdornan on this. And now there is an opportunity to make the situation better for people outside rio (by using right types) and inside rio (by having less interop friction).
Do you think there is any chance of rio not exporting
Builder
? The issue I have is that my code bases tend to be heavily organised aroundBuilder
— the type provided by thetext
package (on whichfmt
and other packages are based).I am not saying that rio should adopt these assumptions but (maybe) be more neutral. I thought I would bring it up in case you weren't aware of a potential barrier/hurdle to adoption.
(I looked for a prior discussion of this issue — sorry if I missed it. I know folks see UTF-16 as a wrong turn and all — it is a pragmatic issue; in the long run we are all dead, like. )