Explore principled port to shapeless

[amnaredo]

Shapeless has already done lots of work 'for us', in trying to handle any number of Scala-internal situations that needn't be re-solved here.

It may be possible to switch away from many contained hand-written macros, to using structures provided by Shapeless' macros.

A priority would be preserving (or improving) /compile/ performance (runtime should be unaffected anyway). This is to allow for example ammonite-repl to continue using upickle-pprint for display.

If we can get this working, in principle it may be possible to (relatively) straightforwardly address

• [ ] #164
• [ ] #167
• [ ] #172
• [ ] #169
• [ ] #166 (maybe?)

... with the further hope that any issues of a similar nature that arise could be redirected upstream to Shapeless.

Existing tests in pprint look like they can be preserved and used as a reference (and compile benchmark, to never slow down from?), with new tests separately added for cases that can't be displayed today.

It should be possible to do this either cleanly against the current codebase, or at least such that the resulting code is very readable/intuitive, to make it easy to review.

ID: 174 Original Author: tekacs

[amnaredo]

Welp, pressed Ctrl-Enter and posted early, before I'd fleshed things out.

This is just an exploration issue, happy to keep it in closed state to avoid generating noise.

To be clear, I'm planning to put some of my spare time in on this; so this isn't a request for work to be done.

(I should hopefully be motivated to come back here every time my (ammonite-)repl hangs or gives me an implicit divergence :smile:)

Original Author: tekacs

[amnaredo]

Yes, I think it may fix all those issues. Or it may not, who knows 😛 or it may introduce new ones.

@alexarchambault has explored this for uPickle; in the end it was significantly slower to compile and run, but there have been many many improvements since then that may have helped. I'd be interested in seeing anther attempt and seeing how it turns out.

We should be able to re-use all the tests; that would be the baseline to ensure that the rewrite is functionally equivalent and doesn't regress. From there, the goodness of the rewrite can then be judged from runtime performance, compile performance and how many of those bugs end up fixed.

Original Author: lihaoyi

[amnaredo]

Well we can try (and probably fail 😛) to keep most new issues external, wash our hands of them and ask the shapeless folks to fix them upstream. 😛

I'd definitely be concerned about compilation speed with shapeless, which is why the plan is to make that a primary focus going in.

A potential avenue I have in mind is to:

• try to stick to the simpler features of shapeless (e.g. don't use HList until we hit case class 23+, if indeed that helps; and watch out for records)
• in line with those simple features, prefer to fail fast at compliation (with 'sorry we can't handle that by default, you can import your own implicit') rather than handle every possible case

That said, you're exactly right - no idea if this approach will work - but it's at least one possible avenue worth exploring to both simplify and get away from the above bugs.

Original Author: tekacs

[amnaredo]

@tekacs @lihaoyi Roughly done here: https://github.com/alexarchambault/upickle-pprint. Recent optimizations in scalac by Miles Sabin (https://twitter.com/milessabin/status/779298833981435904) could make it possibly faster than the hand crafted macros of upickle here.

Original Author: alexarchambault

[amnaredo]

@tekacs Did you have any joy with this? Interested as I have hit issue #167 here and would be happy to experiment wth @alexarchambault 's implementation. Original Author: philglover

[amnaredo]

@philglover I haven't had much of a break since then to pursue it. Would love to see anyone make some progress on this front! :) Original Author: tekacs

[amnaredo]

Automatic deep derivation is gone in 0.5.1, rendering this question moot Original Author: lihaoyi