<div dir="ltr">Hey all,<div><br></div><div>after reading a bit and crosschecking what Ben said, it seems the masterplan should be this (happy path scenario):</div><div><br></div><div>1. Switch away from a String-centric representation for a Doc (to be abstracted, in theory, via typeclasses). This would ensure we can “jack-in” things like FastString or ByteString into pretty, without breaking encapsulation.</div><div><br></div><div>2. (Orthogonal) Remove accidental quadratic complexity in pretty by leveraging special case for infinite band-width case. If I understood correctly this is the scenario we are in when we do the ASM CodeGen phase, where performance matters.</div><div><br></div><div>3. We switch from “GHC Pretty” to “Pretty”, making sure nothing is broken in the process. I know there were some patches which were reverted because they caused a memory regression in the compiler. AFAIK the culprit is unclear. Another complication which is unclear to me is what has been mentioned about “diverging laws”. Looks like there was an ambiguous invariant rule and pretty choose one path, GHC.Pretty the other. Reconciliation is unclear to me in this scenario. Something else unclear is how to reconcile the fact TextDetails in GHC.Pretty contains stuff which is performance and GHC-specific. Maybe we should abstract over TextDetails after all, so that we could jack in a TextDetails representation in a Doc. I don’t know if this path has been attempted yet, probably it was. Does anybody have any experience report?</div><div><br></div><div>4. Profit?</div><div><br></div><div>I’m currently (mostly for fun, to quote Edward Kmett “I reserve the right to get bored and do something else which makes money :P :P) trying to tackle 1., but I have seen valiant knights tried this before being killed by the dragon. Oh dear, I guess I will be the next?</div><div><br></div><div>Last but not least, sorry for hijacking the original spirit of this email (although it’s always perf-related), but throwing my ramblining into those already-packed GHC trac tickets seemed overkill. I have the feeling (not just a feeling) that this has been discussed and explained over and over to new freshmen trying to venture into GHC outlands, so it must be frustrating for you guys to write that down for the 1000+1 time. A big THANK YOU to put up with yet another young apprentice ;)</div><div><br></div><div>Alfredo </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 April 2017 at 20:14, Johannes Waldmann <span dir="ltr"><<a href="mailto:johannes.waldmann@htwk-leipzig.de" target="_blank">johannes.waldmann@htwk-leipzig.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> it would be quite helpful if `pretty`<br>
> gained a special-case for the infinite band-width case<br>
<br>
Absolutely +1 this.<br>
<br>
Not "pretty" but similar:<br>
<a href="https://github.com/jwaldmann/wl-pprint-text/commit/7843d96db57ab01c0be336a5be0d7bca61902005" rel="noreferrer" target="_blank">https://github.com/jwaldmann/<wbr>wl-pprint-text/commit/<wbr>7843d96db57ab01c0be336a5be0d7b<wbr>ca61902005</a><br>
<br>
- J.W.<br>
______________________________<wbr>_________________<br>
</span>Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br></div>