Open parsonsmatt opened 1 year ago
I agree — but I am not aware of plans to fix this. I think the package is regarded as lagacy, anyone caring about performance more more likely to move to one of the more modern alternatives.
This package is used in haddock
since it is a boot package. Rendering HTML is currently a problem for our build at work. I'm investigating a way to fix this without digging into all these guts, but there are some prety low hanging fruit here.
I can put some time/effort into providing a migration.
@parsonsmatt if you want work on this I am very happy to assist — as long as no heavy lifting is involved as I do not have the bandwidth right now. Would you be interested in becomming a maintainer?
Sure! I'd be happy to contribute a bit here.
@parsonsmatt OK consider yourself an xhtml maintainer while I work out how to get you commit rights, etc.
@parsonsmatt if you want work on this I am very happy to assist — as long as no heavy lifting is involved as I do not have the bandwidth right now. Would you be interested in becomming a maintainer?
Tangentially, it might be a good idea to ask CLC to adopt this package as one of core libraries. Dependencies of haddock
are pretty much core ;)
FWIW, I would be very happy for the CLC to pick this up -- I think it makes a great deal of sense.
@cdornan are there any other stakeholders whom I should ask as well? CC @parsonsmatt
@Bodigrim there are no other stakeholders that I am aware of.
CLC has approved adopting xhtml
as a core library in https://groups.google.com/g/haskell-core-libraries/c/_VweuQrNG6c/m/72NtkR_5AwAJ.
I'm investigating the performance of Haddock and noticed that this library uses
String
pervasively.It appears that the majority of the library is using these
String
s not for introspection but for construction and then final rendering. I'd useData.ByteString.Builder
for that.