Generalized, named, and exportable default declarations (GHC Proposal)

newer
serialized data structures (Was:...

Eric Seidel

12 Apr 2021 12 Apr '21

8:54 p.m.

Hi Cafe, The GHC Steering Committee is considering a proposal that would expand the typeclass defaulting mechanism to support arbitrary (single-parameter) classes, and enable exporting defaulting rules. It's received very little input from the community so far, which is a shame because it's trying to address a common complaint about Haskell's String situation. Under the proposal Data.Text could export a rule defaulting IsString to Text. Client modules would automatically import defaulting rules just like class instances, which would make ambiguous string literals automatically default to Text. Please take a look at the proposal and leave your feedback, even if it's just "Yes, this would make my life meaningfully better" (reaction emoji are great for this level of feedback). Gauging the amount of pain caused by problems like this, and weighing that against the cost of new features, is one of the harder parts of being on the Committee. PR: https://github.com/ghc-proposals/ghc-proposals/pull/409 Rendered: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...

Show replies by date

Richard Eisenberg

12 Apr 12 Apr

10:58 p.m.

Hi all, Thanks, Eric, for posting this here. I thought it would also be helpful to link to https://github.com/ghc-proposals/ghc-proposals/pull/396 https://github.com/ghc-proposals/ghc-proposals/pull/396. That proposal describes how a plugin might be designed to help handle defaulting. The proposal was labeled "out of scope" because plugin design is not part of the committee process, but I think it's a good counterpoint to the proposal Eric brought up. There is apparently an implementation of the default plugin scheme and I've encouraged the author to submit it for inclusion in GHC. Thanks, Richard

...

On Apr 12, 2021, at 8:54 PM, Eric Seidel wrote:

Hi Cafe,

The GHC Steering Committee is considering a proposal that would expand the typeclass defaulting mechanism to support arbitrary (single-parameter) classes, and enable exporting defaulting rules.

It's received very little input from the community so far, which is a shame because it's trying to address a common complaint about Haskell's String situation. Under the proposal Data.Text could export a rule defaulting IsString to Text. Client modules would automatically import defaulting rules just like class instances, which would make ambiguous string literals automatically default to Text.

Please take a look at the proposal and leave your feedback, even if it's just "Yes, this would make my life meaningfully better" (reaction emoji are great for this level of feedback). Gauging the amount of pain caused by problems like this, and weighing that against the cost of new features, is one of the harder parts of being on the Committee.

PR: https://github.com/ghc-proposals/ghc-proposals/pull/409 Rendered: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop... _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Henning Thielemann

13 Apr 13 Apr

5:20 a.m.

New subject: serialized data structures (Was: Generalized, named, and exportable default declarations)

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: https://github.com/iu-parfunc/gibbon 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. What if we would not complicate the language and generalize syntactic sugar for Text, but instead improve data layout for all Haskell types and eventually make a custom Text type unnecessary?

Mario

10:58 a.m.

New subject: serialized data structures (Was: Generalized, named, and exportable default declarations)

On 2021-04-13 5:20 a.m., Henning Thielemann wrote:

...

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:

https://github.com/iu-parfunc/gibbon

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.

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.

YueCompl

4:27 p.m.

New subject: serialized data structures (Was: Generalized, named, and exportable default declarations)

I suggest it won't need to be as efficient as Text, just reasonable efficient will suffice. 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. GHC / Haskell's unique trade off w.r.t. optimization may be the new sweet spot in coming years as I feel it.

...

On 2021-04-13, at 22:58, Mario wrote:

On 2021-04-13 5:20 a.m., Henning Thielemann wrote:

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

https://github.com/iu-parfunc/gibbon

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.

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.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Carter Schonwald

6:45 p.m.

New subject: serialized data structures (Was: Generalized, named, and exportable default declarations)

Indeed. I think there’s a few viable directions folks are exploring on the string front. 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!) On Tue, Apr 13, 2021 at 4:30 PM YueCompl via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...

I suggest it won't need to be as efficient as Text, just reasonable efficient will suffice.

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.

GHC / Haskell's unique trade off w.r.t. optimization may be the new sweet spot in coming years as I feel it.

...
On 2021-04-13, at 22:58, Mario wrote:

On 2021-04-13 5:20 a.m., Henning Thielemann wrote:

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

...
https://github.com/iu-parfunc/gibbon

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.

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.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

YueCompl

14 Apr 14 Apr

3:41 a.m.

New subject: serialized data structures (Was: Generalized, named, and exportable default declarations)

As for text handling: [There Ain’t No Such Thing As Plain Text.](https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-softwar...) [What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text](https://kunststube.net/encoding) Just some random hits from google search, thanks to globalization, variable-byte-width and even variable-byte-order is the norm today, I see package text hasn't catchup yet: http://hackage.haskell.org/package/text

...

Currently the text library uses UTF-16 as its internal representation which is neither a fixed-width nor always the most dense representation for Unicode text. We're currently investigating the feasibility of changing Text's internal representation to UTF-8 and if you need such a Text type right now you might be interested in using the spin-off packages text-utf8 and text-short.

I do think Haskell can excel at managing compact annotative data structures around raw utf-8 bytes as the major payload, and foster sophisticated manipulation APIs beyond counting and slicing with the out-dated fixed-width character assumption.

...

On 2021-04-14, at 06:45, Carter Schonwald wrote:

Indeed.

I think there’s a few viable directions folks are exploring on the string front.

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

On Tue, Apr 13, 2021 at 4:30 PM YueCompl via Haskell-Cafe wrote: I suggest it won't need to be as efficient as Text, just reasonable efficient will suffice.

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.

GHC / Haskell's unique trade off w.r.t. optimization may be the new sweet spot in coming years as I feel it.

...
On 2021-04-13, at 22:58, Mario wrote:

On 2021-04-13 5:20 a.m., Henning Thielemann wrote:

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

https://github.com/iu-parfunc/gibbon

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.

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.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

1497

Age (days ago)

1498

Last active (days ago)

List overview

Download

6 comments

6 participants

participants (6)

Carter Schonwald
Eric Seidel
Henning Thielemann
Mario
Richard Eisenberg
YueCompl