Remove Builder?

[cdornan]

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 around Builder — the type provided by the text package (on which fmt 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. )

[snoyberg]

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.

[cdornan]

@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.)

[cdornan]

(I have my answer — please close the issue, but I am curious about the Display roadmap.)

[snoyberg]

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.

[cdornan]

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]).

[akhra]

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).

[cdornan]

Yes, logging was the other item on my list but only to mention it and see what the issues were.

[snoyberg]

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.

[dpwiz]

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?

[snoyberg]

No, neither of those changes affect the motivations described here.

[dpwiz]

What would it take to implement "a more full-featured text display approach" that is available outside rio?

[snoyberg]

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.

[dpwiz]

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).