<div dir="auto">Indeed.  </div><div dir="auto"><br></div><div dir="auto">I think there’s a few viable directions folks are exploring on the string front. </div><div dir="auto"><br></div><div dir="auto">As for rules based optimization, I think that there’s room for more robust systems, eg can any of the ideas in for example the egraphs good paper from popl 2021 or the associated egg library be adapted to allow for more robust optimization in ghc or similar language for fusion?  I suspect yes, but with some serious work around cost model and how unfolding is done (we shouldn’t need to inline to allow fusion that results in choosing to inline!)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 13, 2021 at 4:30 PM YueCompl via Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suggest it won't need to be as efficient as Text, just reasonable efficient will suffice. <br>
<br>
C++'s mantra of “you don’t pay for what you don’t use” is overly emphasizing on the machine aspect on today's stand point, as machine price (hardware purchase, energy consumption for the run, time to result) descending and human price (programmer / analyst / management mental overhead, time to production deployment, bug tracking & resolution, maintenance & service) ascending, more and more orgs will be willing to pay reasonably more on machines to save the cost on humans.<br>
<br>
GHC / Haskell's unique trade off w.r.t. optimization may be the new sweet spot in coming years as I feel it.<br>
<br>
> On 2021-04-13, at 22:58, Mario <<a href="mailto:blamario@rogers.com" target="_blank">blamario@rogers.com</a>> wrote:<br>
> <br>
> On 2021-04-13 5:20 a.m., Henning Thielemann wrote:<br>
>> <br>
>> We have seen a lot of effort of better integrating Text into Haskell programming. The only purpose of doing so is to replace String by something more space and time efficient. What would happen if we invest equally much time into making String as efficient as Text? At ICFP 2019 I attended a talk about Gibbon:<br>
>> <br>
>>    <a href="https://github.com/iu-parfunc/gibbon" rel="noreferrer" target="_blank">https://github.com/iu-parfunc/gibbon</a><br>
>> <br>
>> The idea of the project is to serialize (Haskell's) tree data structures in memory as much as possible. Wouldn't this enable us to use String instead of Text, again, maybe even lists instead of Vectors? No more Text integration efforts, no more external library with GHC-specific manual optimizations. Unfortunately, the project is still in an early stage. So far, it only supports strict data structures.<br>
> <br>
> <br>
> I don't want to be unfair to the project without investigating it closer, but my feeling is that it goes against the spirit of the times. There's been some disillusionment with the shortcut fusion, rule-based rewriting, and similar advanced techniques. It's probably been inevitable that, as GHC slowly shifts from research and teaching to industrial use, the community would get jaded with amazing but flukey research results and put more value on boring predictability instead. Unless Gibbon can make String perform *consistently* as efficient as Text, I don't see the project gaining adoption.<br>
> <br>
> <br>
> _______________________________________________<br>
> 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-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
_______________________________________________<br>
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-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>