Cats: Add Priority / OrElse implicit search helper

[alexandru]

Samples:

1. https://github.com/typelevel/algebra/blob/master/core/src/main/scala/algebra/Priority.scala
2. https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/orelse.scala

I've also encountered cases in which I wished to have this helper available with the Async / Concurrent type classes in Cats-Effect. So it would work like this:

1. if a Concurrent instance is in scope, build a cancelable task via Concurrent.cancelable
2. if only an Async instance is in scope, as a fallback, build an atomic task via Async.async

So this is a mechanism for optimizing the implementation in case a type class instance is available, or otherwise use the default. This optimization problem is also relevant for Haskell: https://stackoverflow.com/questions/44250854/use-specialized-implementation-if-a-class-instance-is-available

I think it's time we add something like this to cats-kernel.

[johnynek]

This would be good. A common example is having a Group vs a Monoid can make a perf difference.

That said, this approach has been criticized since it encourages the user to ignore perf impacts.

[ceedubs]

I'd be inclined to put this into a micro project. It doesn't seem directly related to Cats, and I don't think that Shapeless is going to depend on Cats Kernel, but it could potentially depend on this micro project (I assume that it could be an extremely stable lib).

[djspiewak]

I don't have a strong opinion on this, but I'd like to note that these sorts of helpers often have to take subtly but critically different forms depending on application. For example, here's a variant of OrElse in shims: https://github.com/djspiewak/shims/blob/8ab307f0837e11505e0e958879c6889176f9ac9f/core/src/main/scala/shims/util/capture.scala#L33-L40

I need a custom version for two reasons:

• Macro-based workaround for a bug in Scala's implicit search related to cyclic falsification of non-top-level inductive implicit possibilities (FYI Dotty doesn't have this bug)
• Preservation of the specific type of the injected implicit, rather than the generic supertype being searched (example call site, but note now the macro will explicitly refuse to capture something that is a subtype of Synthetic)

I honestly agree with @ceedubs: it seems a little odd to put something like this into cats (even cats-kernel).

[johnynek]

y'all's build pain tolerance is so much higher than mine if you want to put a single scala file into it's own sbt/travis/mima/sonatype nightmare.

[djspiewak]

@johnynek Or we just have plugins and templates which take care of it for us. :-D Can recommend. I can spin up and publish a microlibrary which contains OrElse in about the same amount of time it took me to type this comment.

[SystemFw]

@djspiewak Would be interested to see some of these templates and plugins since, while I do have some automation, this part is still painful for me :)

[johnynek]

it is shame we need plugins and templates for this which evidently are not widely shared.

I'd also love to measure time to set up new repo and see how we can teach or tool that down.

For me it is definitely hours. I can write a lot of code in that time, and I actually enjoy it. Here was a recent time I almost rage quit programming:

https://github.com/johnynek/unuhi/pull/2

I'm certainly not great at this, but I don't want to be. It seems there should be almost no "hair" on these things: code is in this directory, here's the project name, here's the version. BOOM. But I have to futz with a build matrix, get the commands right, etc...

copypasta is for go-fans. I want a dry build that works and is easy.

[djspiewak]

@johnynek @SystemFw This is definitely getting a bit off-topic for the thread at hand, but it's an important subject and I don't want it to get lost in the wash.

The reason that these sorts of plugins don't get widely shared/used is simply that they are, by definition, quite specialized. Or at least, that would be the perception of the authors (such as myself). Just off the cuff, if you used my plugin and associated giter8 template, you would need to accept the following restrictions, or at least defaults:

• Versioning exclusively by git state
  
  
  
  • Tags of the form v1.2.3
  
  
  • Seven-character truncated hashes appended to baseVersion for untagged releases
  
  
  • Also a rather opinionated approach to snapshots
  
  
• Scalaver (semver with breakage allowed in the second component)
• sbt-gpg
• Coursier
• sbt-header
  
  
  
  • Defaulting to ASLv2
  
  
• A whole slew of Scala compiler options (pretty close to what @tpolecat famously advocates)
  
  
  
  • SI-2712 fixes galore
  
  
• Travis
• Publishing from your local machine, rather than from CI (this is a vastly more secure default for most non-organizations)

Some of these things are a bit extraneous to the goal of getting a project off the ground and publishing (e.g. the scalac options), but some that seem extraneous are actually necessary (e.g. sbt-header).

Do you want to accept those limitations, or at least those defaults? Not a rhetorical question, I honestly want to know! There are other plugins out there which also attempt to address this niche (sbt-rig for one). Would you be happier with their opinions and restrictions? Now you have to choose from a menagerie of possible tradeoffs.

So you see why no one has stepped forward and said "hey guys, do it this way". I'm more than happy to point people to my plugin and say "I think I'm right, you should also think I'm right!" but I can't in good conscience say something like that without dropping the above set of caveats, because so much of this stuff is subjective.

Push-button solutions are possible – my giter8 template is actually very close to exactly this, especially if your name happens to be Daniel Spiewak – but they always require accepting some specific design decisions and esoteric opinions on publication. Would the Scala community benefit from having one (or perhaps two?) such "de facto push-button solutions" to this problem? Or would that just make things worse as people feel the weight of the restrictions and defaults that someone else chose for them?

[SystemFw]

Thanks for the answer Daniel :)
I'll take some time to chew on it and evaluate

[johnynek]

@djspiewak these options look good to me (except not using semver directly).

More to the point I am willing to compromise so we can make this process simpler. I think we really need to make it easier to make and publish scala libraries. I fear the actual library producing community in scala is actually very small. We need to grow that.

I’m not sure if any popularly used language is harder to publish a library for than scala, but it would be interesting for us to be the very easiest to make a new library for.

[djspiewak]

@johnynek We should start looking for a different venue in which to have this conversation. 😊 I think it’s solvable. I really do. So long as the compromises are consciously accepted.

Semver is probably a better default. I don’t mind that. People can always encode less strict semantics if they need them, but it’s a bit of a nudge in the right direction.

I’m not sure Scala can ever be the easiest. At least not if you want to publish to Sonatype. Group ID claiming is important due to the size and impact of the Java ecosystem, but it makes the up front cost of first time publication much higher. I think we need to try to lift some of the stigma surrounding third party resolvers and allow people to use bintray more, because that’s probably the only way we can reduce the first time setup cost below “horrifying”.

[alexandru]

As an update, I've published a micro-library for this here:

https://github.com/monix/implicitbox