Support for enrichment of standard library classes

[benhutchison]

This issue began with I posted a question to cats gitter - is there support for conversion of Boolean to Option values, like the option[A](a: A) method in Scalaz.

Two other example where people have/want-to enrich standard lib classes with extra behavior:

• Issue Add cata to syntax.option #749
• https://github.com/non/cats/blob/master/core/src/main/scala/cats/syntax/option.scala#L26

The scalaz.syntax.std package has a bunch more that could be supported if/when useful or requested, egs:

• BooleanOps
• ListOps

Opinion seemed to run against adding such "conveniences" into cats core in general, eg @travisbrown response. But in following discussion there seemed to be agreement they have value and for putting them somewhere in a new module or project (working title extra-syntax).

Our immediate goals are to answer:

1. What should the scope/charter of extra-syntax be? I'd say the primary goal is Improvement/enrichment of the standard library classes, with secondary goal increase familiarity & portability for Scalaz programmers.

   The principle I stumble to articulate though is, when does code go into extra-syntax vs cats syntax?

   Proposal:

   • conversions of std types to cats datatypes (eg Option => Xor) go into cats core
   • methods that enable/support using cats typeclasses go into cats core

   Anything else goes to extra, such as conversions between std types, or extra methods like option.cata.

   Or is the distinction more about barrier-to-entry/level-of-consensus? If everyone agrees its central, it can go to cats core, if there's doubt its goes to extras? Not too keen on this, I'd prefer a more objective criteria ideally..

2. Should it be a new project or a new module? My feeling at present is that it'll prove to be pretty small, only the most valuable tip of scalaz.syntax.std will be requested, and so a module with cats is preferable to another project. Not a strongly held position however.

[dwijnand]

Perhaps Stacy Curl's Pimpathon project might be of interest here: https://github.com/stacycurl/pimpathon

[travisbrown]

@dwijnand I think there would definitely be advantages of having a library or module like this with a Cats dependency (in particular for things like string-to-number parsers that return Validated).

Also this.

[dwijnand]

I also don't like the name.

And yes such a library would need to depend on cats, perhaps in a foo-cats module.

[milessabin]

Paging @stacycurl ... time for a name change?

[stacycurl]

I think you know that I'm very fond of the name, I think of an exuberance of bling, etc & nothing to do with sex. No one has approached me saying they are offended, but then few are using it.

I enjoy the independence of taking it whichever way I wish (I have maintained backwards compatibility though), you are very welcome to scrutinise it for ideas (and mistakes).

[philwills]

I think the criteria @benhutchison proposes make sense for whether it should be in core or an extra module/library.

String to number with Validated is something I've rolled my own of recently, so I can definitely see the use case.

[ceedubs]

@benhutchison should we close this out now that https://github.com/benhutchison/mouse is a typelevel incubator project?

[benhutchison]

Yes, belatedly. apologies missed this mention somehow...