These are chat archives for typelevel/cats

31st
May 2016
Marius B. Kotsbak
@mkotsbak
May 31 2016 00:06
Hmm, why is traverse defined for List, but not Seq=
Rob Norris
@tpolecat
May 31 2016 00:07
Seq isn't a functor because it can be mutable; it fails the identity law.
So it can't be a traversable functor, monad, etc.
Erik Osheim
@non
May 31 2016 00:08
right, or more specifically, it isn't guaranteed to be referentially transparent in general
in light of the recent alleycats discussion i want to actually write up a doc about laws and law-checking
Rob Norris
@tpolecat
May 31 2016 00:12
I think that would be really helpful. We talk about laws a lot but there are not a lot of explanations out there. A few years back Nick Partridge did an intro talk about laws and why they're important and that's the only one I have ever seen.
Marius B. Kotsbak
@mkotsbak
May 31 2016 06:56
Hmm, so why is Seq used everywhere, e.g. in Slick then?
Gary Pamparà
@gpampara
May 31 2016 07:45
@mkotsbak The illusion of abstraction. The fact that they say the default is Vector is just by chance. It could change at any time, but people still use Seq for some reason.
Marius B. Kotsbak
@mkotsbak
May 31 2016 09:01
ok
nafg
@nafg
May 31 2016 09:02
I think it used to be List, before Vector was added
But what do you mean "by default"
Seq doesn't "mean" Vector at all, just the default factory is (Seq() or Seq(1, 2, 3))
The fact is that if you want to allow any subclass of Seq, you can write Seq. There's no other way to allow any subclass of Seq (without a lot of pain anyway...)
So yeah, maybe Slick wants to be able to change what collection they use
Wizziee
@WizzieP
May 31 2016 10:25
Hi - is there mapAccum (map with accumulator) or is there any plan to have it in cats?
Cody Allen
@ceedubs
May 31 2016 12:03
@WizzieP there currently isn’t one in cats. I would typically use State if I were going to do something like that, but I’m not opposed to adding that sort of helper method if people would like to have it
Peter Neyens
@peterneyens
May 31 2016 12:08
Is there a reason why Eval is not in cats.data ?
Marius B. Kotsbak
@mkotsbak
May 31 2016 12:18
This is a common pattern here: XorT.fromXor(Xor.fromOption have you thought about adding XorT.fromOption directly?
Erik Osheim
@non
May 31 2016 13:29
@ceedubs want to give another +1 on this? typelevel/cats#1072
Cody Allen
@ceedubs
May 31 2016 13:31
@non :thumbsup: done
Erik Osheim
@non
May 31 2016 13:32
thanks!
Peter Neyens
@peterneyens
May 31 2016 13:32
Wow, that went quick :clap:
Erik Osheim
@non
May 31 2016 13:33
@peterneyens others have asked. originally i thought since Eval was being used heavily in a lot of our APIs it should be available in cats._ but maybe it's still confusing for folks? if you want to open an issue i'd be interested in people's thoughts. it's certainly a bit inconsistent.
(certainly Xor is also showing up in our APIs and it's in cats.data._)
Peter Neyens
@peterneyens
May 31 2016 13:34
It seems to be the only non type class in cats._, that's why I asked.
Erik Osheim
@non
May 31 2016 13:36
@ceedubs did you want me to submit a PR adding a runTailRec method to Free?
or do you want to put together a bolder proposal?
Cody Allen
@ceedubs
May 31 2016 13:38
@non runTailRec ends up becoming equivalent to foldMap(FunctionK.id) after #1075, doesn’t it?
not that we couldn’t have an optimized runTailRec - just to see if I’m understanding
Erik Osheim
@non
May 31 2016 13:42
yes, that's correct.
so maybe we don't even need to bother, haha!
but yeah, i still support something that just plugs in FunctionK.id for you.
(or even an optimized version)
Cody Allen
@ceedubs
May 31 2016 13:43
@non :thumbsup: to a PR for either approach, though we’ll probably want to wait for #1075 to be merged
Erik Osheim
@non
May 31 2016 13:44
yeah i'll wait for a bit
also -- i want to include those toString fixes.
Cody Allen
@ceedubs
May 31 2016 13:45
:thumbsup: I forgot about those
@non I probably have a slight preference for plugging in id, because I think that ensuring that any bugs that are fixed in one are fixed in the other is probably worth the overhead of an extra FunctionK allocation and some extra identity method calls that I would expect to be trivial compared to the other overhead of foldMaping a Free
(btw if we are feeling dirty I think we could have FunctionK.id reuse a singleton instance with an asInstanceOf)
Cody Allen
@ceedubs
May 31 2016 13:52
@non regarding the toString fixes - I’m wondering if we should just make GoSub no longer a case class. The toString it gains is problematic, and the equals is pretty meaningless.
Rob Norris
@tpolecat
May 31 2016 14:01
@mkotsbak the prevalence of Seq in "mainstream" scala libraries doesn't have a good explanation as far as I know. It may go back to varargs begin wrapped arrays (the spec says they have type Seq[A]). Dunno. It's unfortunate.
Cody Allen
@ceedubs
May 31 2016 14:23
@tpolecat I think that Seq shouldn’t be used and that there are better approaches to abstracting over collections. However, I don’t think that I’m sold on the idea that we shouldn’t provide a Foldable[Seq] in one form or another. I think people know that all bets are off if you mutate a collection while you are in the middle of folding over it. And sure a Seq could be mutable or infinite, but a Stream could be infinite and we still let you do Foldable[Stream].foldLeft...
I often find myself in a situation where some code has given me a Seq and in order to use it in any of my typeclass-based code I have to call toVector or something on it, which seems like a really inefficient approach if I just want to fold over it
Cody Allen
@ceedubs
May 31 2016 14:28
I guess I view it kind of like Xor.catchNonFatal — sure I don’t want code to throw exceptions. But if you are working in scala you are going to run into code that does, so it’s nice to have a way to deal with that in an FP-friendly way. Sure, I don’t want people to use Seq, but when I run into it it seems like I should be able to fold over it.
Rob Norris
@tpolecat
May 31 2016 14:30
My vote is for alleycats.
Cody Allen
@ceedubs
May 31 2016 14:31
Yeah, I’m fine with this sort of thing not being in core.
Rob Norris
@tpolecat
May 31 2016 14:32
People have argued along similar lines that Functor[Array] is ok as long as you don't mutate the array. So I don't want that kind of notion to get a foot in the door.
tpolecat @tpolecat takes off "that guy" hat
Cody Allen
@ceedubs
May 31 2016 14:34
@tpolecat I think it may already have a foot in the door. @non had some proposals that he introduced as "controversial" when he and I met up yesterday :)
don’t have time to delve into it at the moment and I don’t want to mischaracterize his ideas so I’ll let him introduce the ideas if he wants to
Miles Sabin
@milessabin
May 31 2016 14:36
Yes to it being in alleycats if alleycats can be a submodule.
Cody Allen
@ceedubs
May 31 2016 14:38
yeah I guess the gist of the idea is that alleycats should be a submodule and people who add an uber dependency and import for cats should get things like Foldable[Seq], because letting them get a Foldable[Seq] but only if they know the secret code for the dependency and import is just making it tougher to transition to FP
Miles Sabin
@milessabin
May 31 2016 14:39
:+1:
Cody Allen
@ceedubs
May 31 2016 14:39
I think that I could be convinced either way on this. On the one hand, I will want a strict import when I use cats. On the other hand I do like making it easier for people to transition code to be more functional in nature
well I guess those aren’t two separate hands. I’m free to use a more strict import than others.
Miles Sabin
@milessabin
May 31 2016 14:40
And live with other peoples code that they have no control over.
Cody Allen
@ceedubs
May 31 2016 14:40
I guess the "one hand" is that I don’t want to trip people up by providing instances that may have gotchas that they may not know about
Miles Sabin
@milessabin
May 31 2016 14:41
Agreed.
But we shouldn't put obstacles in the way of people who've made an informed choice.
... excessive obstacles ...
Releasing the safety catch is reasonable.
Rob Norris
@tpolecat
May 31 2016 14:49
@ceedubs are you suggesting that you should get it for free but it requires an eplicit import?
Cody Allen
@ceedubs
May 31 2016 14:52
@tpolecat I guess that depends on what you mean by "for free". Erik did a pretty good job of convincing me that for instances that are safe under reasonable circumstances (not mutating mid-op, throwing exceptions, etc), adding the uber dependency and import should get them for you. Whereas people who want the strict subset would just add cats-core and import cats.strict._ or something like that
Erik Osheim
@non
May 31 2016 14:52
so yeah, i was going to write a gist, but my thinking is that there should be a separate submodule, but that it's possible that either cats.implicits._ or something like it live there, and that the "beginner guide" encourages people to get everything.
and in the hypothetical FAQ we can explain that cats-core is strict, whereas the other module is not, and that based on your project and collaborators you can choose which to use
Rob Norris
@tpolecat
May 31 2016 14:54
"mutating mid-op" doesn't capture the essence of lawbreaking … array and array.map(id) are not the same thing if you mutate anywhere in your program, not just while you're mapping.
Cody Allen
@ceedubs
May 31 2016 14:54
on the other hand, I can see some potential benefit in people asking "but why isn’t there a Functor[Array] here?"
Erik Osheim
@non
May 31 2016 14:54
@tpolecat right, for a strict definition of "the same"
Rob Norris
@tpolecat
May 31 2016 14:55
Programs should be invariant under lawful substitution. Thats' what I mean by "the same".
Cody Allen
@ceedubs
May 31 2016 14:55
@tpolecat yeah I guess that depends heavily on your defintion of "the same". Is it universal equality? :)
Erik Osheim
@non
May 31 2016 14:55
but our laws are flexible about what IsEq means -- so with a relaxed notion of sameness you can prove that some Functor[Array] instances are quasicorrect while others are wrong.
Rob Norris
@tpolecat
May 31 2016 14:56
@ceedubs no, it's invariance of behavior in the RT sense.
Cody Allen
@ceedubs
May 31 2016 14:56
in before @tpolecat brings up referential transparency and substitution, which I find to be a convincing argument
okay in after
Rob Norris
@tpolecat
May 31 2016 14:57
You guys know this stuff, you can auto-tally my vote in all such discussions without me showing up ;-)
Erik Osheim
@non
May 31 2016 14:57
<3
Rob Norris
@tpolecat
May 31 2016 14:57
Gotta run, enjoy!
Erik Osheim
@non
May 31 2016 14:57
see you later!
Cody Allen
@ceedubs
May 31 2016 14:58
@tpolecat :). Talk to you later.
Erik Osheim
@non
May 31 2016 14:59
the intuition here is that even with things we are comfortable calling immutable/RT there are usually tricks you can use (reflection, toString, universal equals, whatever) to break it. so we agree by convention that those uses "don't count" as far as the subset of behavior we consider to be law-abiding.
one great example here is:
scala> val f = (n: Int) => n + 1
f: Int => Int = <function1>

scala> val g = f andThen identity
g: Int => Int = <function1>

scala> (f == f, f == g)
res0: (Boolean, Boolean) = (true,false)
Cody Allen
@ceedubs
May 31 2016 15:01
@non while I still don’t see much harm in something like Foldable[Seq] (or even Iterable probably), I think Rob has convinced me that something like Functor[Array] is more troublesome, since you do lose the ability to be able to apply mathematical substitution
and I guess even Functor[Seq] by the same notion
Erik Osheim
@non
May 31 2016 15:03
yeah i mean, i think array is maybe pushing it, but i think this argument holds a lot of water for e.g. Functor[Set], something that there is still a lot of approbation over.
Cody Allen
@ceedubs
May 31 2016 15:03
that’s not to say that I would completely write it off as a possibility, but I do think it’s another tier of potentially problematic
Dale Wijnand
@dwijnand
May 31 2016 15:06
Functor[immutable.Seq]
Erik Osheim
@non
May 31 2016 15:06
the argument against arrays is compelling because if you accept it you can see that using an array as an "input" to a law will never work -- arrays are never intersubstitutable except trivially.
if you accept that in some ways it becomes easier to argue for things like Monoid[Seq[A]] though. for any well-behaved Seq[A] values you can show that the laws hold. and most of our laws fail if you let people check them with poorly-behaved values.
(for example, things using null, functions that throw or hang, things that use reflection, using eq, universal methods, etc)
anyway, i'll write up a formal proposal, attach an automatic -1 from @tpolecat, and see how everyone else feels about it ;)
Cody Allen
@ceedubs
May 31 2016 15:12
@non I’m less concerned about the universal equality of Array and more about something like this:
def noop[F[_]:Functor, A](fa: F[A]): F[A] =
  fa.map(identity) // or just fa

val program: Array[Int] = {
  val x = Array(1, 2, 3)
  val y = noop(x)
  y += 1
  x
}
the result of program depends on whether noop returns fa.map(identity) or simply fa
Erik Osheim
@non
May 31 2016 15:14
right.
Cody Allen
@ceedubs
May 31 2016 15:14
so even if you aren’t concerned about whether .map(identity) results in something that is equal according to equals, you still have the fact that it affects whether you are able to replace code with a val
Erik Osheim
@non
May 31 2016 15:15
that's true. once you are mutating arrays any bets you made about RT involving those arrays are gone
Cody Allen
@ceedubs
May 31 2016 15:16
this is a simple and probably silly example, but it seems plausible to me that this sort of thing could result in less obvious issues

anyway, i'll write up a formal proposal, attach an automatic -1 from @tpolecat, and see how everyone else feels about it ;)

sounds like a plan :)

Miles Sabin
@milessabin
May 31 2016 15:44
RT in Scala (and Haskell for that matter) will always be an approximation. The only real issue is just how fuzzy we're happy to be.
I'm happy with an import being required for lawless instances.
Can we have a less pejorative word that "lawless"? How about unconstrained?
Dale Wijnand
@dwijnand
May 31 2016 15:47
impure?
Miles Sabin
@milessabin
May 31 2016 15:52
That's overloaded and also pejorative ;-)
Empty for instance is just unconstrained.
It's definitely a different kind of "lawless" than Foldable[Seq].
Rob Norris
@tpolecat
May 31 2016 15:55
To me "lawless" means "doesn't introduce a new substitution rule" so maybe a word that hints at that?
Miles Sabin
@milessabin
May 31 2016 15:55
OK, that's crystallised my worry about this ... I don't think it's reasonable to treat alleycats (whether it's internal or external) as a sin bin for stuff that people have qualms about. Different classes are "lawless" in different ways.
@tpolecat I still think that's problematic. You should say "doesn't introduce a new substitution rule on it's own".
Empty and Foldable[Seq] are very different in this respect.
Rob Norris
@tpolecat
May 31 2016 15:57
Right.
I guess I would say that Empty is lawless, but Monoid gives rise to an Empty that introduces left and right identity.
And since there can only be one Empty that has to be it.
tpolecat @tpolecat runs
Rob Norris
@tpolecat
May 31 2016 15:59
Foldable is a weird one. I don't know what to think about it.
Miles Sabin
@milessabin
May 31 2016 16:00
Interestingly I think that Empty and Foldable[Seq] are at opposite ends of a spectrum ... Empty is pure but underdetermined, whereas Foldable[Seq] is impure but determined (in the sense that if it isn't tampered with it should have a determinate answer).
Rob Norris
@tpolecat
May 31 2016 16:01
Empty defines an introduction and foldable defines an elimination.
Maybe. ;-)
Miles Sabin
@milessabin
May 31 2016 16:02
Well, we could have Pure and Copure.
Sorry, we have Empty and Extract.
Those do define introduction and elimination rules.
The issue with Foldable[Seq] is more related to the Seq IMO ;-)
Simone Scarduzio
@sscarduzio
May 31 2016 17:44
hey guys, I can’t figure out what to import to make the home alone operator work in Validated: I’m trying to make Noel Welsh’s example compile with the latest version of cats..
https://gist.github.com/sscarduzio/c9be2b6636311e5f8740c50b094a382e
Cody Allen
@ceedubs
May 31 2016 17:46
@sscarduzio change import cats.syntax.apply._ to import cats.syntax.cartesian._ I think
Erik Osheim
@non
May 31 2016 17:51
does anyone want to give a +1 to #1075? also -- @TomasMikula could you merge/rebase that PR? it seems like there is some kind of conflict
Peter Neyens
@peterneyens
May 31 2016 17:51
I think one NaturalTransformation needs to be renamed to FunctionK after my PR got merged
Erik Osheim
@non
May 31 2016 17:54
@peterneyens seems likely. if you see it do you want to open another PR?
oh wait, you meant in that PR! yeah
sorry 😳
Peter Neyens
@peterneyens
May 31 2016 17:56
I meant #1075 yes.
Simone Scarduzio
@sscarduzio
May 31 2016 17:59
@ceedubs Very good, it worked. Thanks!
Cody Allen
@ceedubs
May 31 2016 18:01
@sscarduzio you’re welcome. FYI the easiest approach is to import cats.implicits._ and not use these specific imports.
Simone Scarduzio
@sscarduzio
May 31 2016 18:12
got it, much simpler to remember.
Dale Wijnand
@dwijnand
May 31 2016 18:33
Question for the crowd: what about just putting the implicits on the cats package object? imports cats._ is even easier to remember.
Michael Pilquist
@mpilquist
May 31 2016 18:33
@dwijnand I often want all implicits from cats, but not all types from cats
Dale Wijnand
@dwijnand
May 31 2016 18:34
And on a similarly extreme note: ditch all the a la carte implicit imports
Michael Pilquist
@mpilquist
May 31 2016 18:34
Or rather, I want some subset of implicits from cats but I don't care to specify which
Erik Osheim
@non
May 31 2016 18:34
yeah -- if we do that it's hard to get all the instances without all the type classes (or vice versa)
@dwijnand i'm sympathetic to your second point -- it seems like a lot of folks use the a la carte imports when they are getting started and get stuck/frustrated.
Rob Norris
@tpolecat
May 31 2016 18:35
scalaz put them on another object which worked well; i.e., scalaz._, Scalaz._
Dale Wijnand
@dwijnand
May 31 2016 18:35
@mpilquist how come not all the typeclasses and data types? Name clashes?
Michael Pilquist
@mpilquist
May 31 2016 18:35
yeah name clashes
well name clashes and ease of reading code
Dale Wijnand
@dwijnand
May 31 2016 18:36
What clashes?
Michael Pilquist
@mpilquist
May 31 2016 18:36
folks shouldn't need to care where implicit instances come from, but i do want to show where various types are coming from
Dale Wijnand
@dwijnand
May 31 2016 18:37
Oh I see how you mean
An alternative is having the implicits available on both: so import cats._ for all the things; and import cats.Functor, cats.implicits._ for your use case
But it might be too easy to get ambiguous imports that way..
Miles Sabin
@milessabin
May 31 2016 18:39
IMO the only sensible approach is to use the implicit scope and only import instances in exceptional circumstances.
Dale Wijnand
@dwijnand
May 31 2016 18:39
export hook 2.0?
Miles Sabin
@milessabin
May 31 2016 18:39
There's work (in the compiler and/or typeclassic) to do to make that work properly.
Typeclassic.
Dale Wijnand
@dwijnand
May 31 2016 18:40
Right
Michael Pilquist
@mpilquist
May 31 2016 18:41
as long as call-site IDE support works, i'm game for solving it with typeclassic
Erik Osheim
@non
May 31 2016 18:41
@milessabin recently @johnynek noticed that the "inheritance problem" of implicit scopes is somewhat ameliorated if you put the most specific instance in the most general type class' companion.
for example, you would put the Field[Double] instance in the Semiring companion object.
spire switched to using imports to deal with issues where instances couldn't be found due to the limitations of implicit scope (searching superclasses but not subclasses). i should talk to @tixxit about whether this approach would work in more places. i'm not totally sure but it's interesting.
Miles Sabin
@milessabin
May 31 2016 18:43
That can work within a single library, but it's painfully anti-modular in general.
Erik Osheim
@non
May 31 2016 18:43
(for context, in spire we have something like Field[A] <: Ring[A] <: Semiring[A])
@milessabin right. that's been the argument against using implicit scope in most cases.
Miles Sabin
@milessabin
May 31 2016 18:44
Wait ... we've had this conversation before, no?
Erik Osheim
@non
May 31 2016 18:44
sort of. the new contribution was using the topmost super class (which i don't think we mentioned?)
Miles Sabin
@milessabin
May 31 2016 18:44
Sure, but I have plans afoot to fix that ;-)
P. Oscar Boykin
@johnynek
May 31 2016 18:44
I don’t know if I follow the anti-modularity
so, if Ring has a low priority provider looking up, what is the problem?
Miles Sabin
@milessabin
May 31 2016 18:44
This is the subclass instance case from export-hook.
P. Oscar Boykin
@johnynek
May 31 2016 18:45
the case where you want to extend Field?
Erik Osheim
@non
May 31 2016 18:45
right, i think so.
Dale Wijnand
@dwijnand
May 31 2016 18:45
@non Should I submit a PR nuking the ala carte imports?
Miles Sabin
@milessabin
May 31 2016 18:45
I added that specially for you :-)
Erik Osheim
@non
May 31 2016 18:45
@dwijnand i'm fine with you either opening an issue to discuss it, or doing a PR to discuss it (if you don't mind the possibility that folks will decide not to merge it)
Dale Wijnand
@dwijnand
May 31 2016 18:46
Rejecting PRs is healthy IMO.
Easier to argue a point with impl as well.
Miles Sabin
@milessabin
May 31 2016 18:46
@johnynek suppose I create a subclass of Field ... now I have to lobby Spire to include its instances in Semiring.
Erik Osheim
@non
May 31 2016 18:47
right, that's true. but i'd feel bad if someone did a ton of skut work expecting it to get merged and then people decided they didn't want it.
P. Oscar Boykin
@johnynek
May 31 2016 18:47
yeah, or live with weak inference
Miles Sabin
@milessabin
May 31 2016 18:47
We can fix the semantics to work the way we want.
Well, that's my claim anyhow.
Gotta run ...
Erik Osheim
@non
May 31 2016 18:48
see you later!
Dale Wijnand
@dwijnand
May 31 2016 18:48
@non Yeah I know what you mean. I think a good way to avoid that is to recommend and nurture a culture of early pull requests for early review. (There's a concept of 30% vs 90% ready review).
30% feedback
Erik Osheim
@non
May 31 2016 18:49
right, that makes sense.
Markus Hauck
@markus1189
May 31 2016 19:16
Did I somehow miss it, or is there currently no easy way to get alternative Monoid instances like e.g. (Int,*) instead of the standard one (Int,+)?
or min/max etc
Cody Allen
@ceedubs
May 31 2016 19:17
@markus1189 you are correct - those currently don’t exist. See also #425
Markus Hauck
@markus1189
May 31 2016 19:19
thanks @ceedubs guess I'll have to do it manually then ;)
Adelbert Chang
@adelbertc
May 31 2016 19:22
@non @dwijnand i've started doing that - submitting PRs with no tests and letting it sit for a while. if no objections then i assume folks are OK with it and add tests and clean stuff up
Dale Wijnand
@dwijnand
May 31 2016 19:56
:+1:
Ashic Mahtab
@ashic
May 31 2016 20:07
Say, I have val a: XorT[Future, Throwable, Int]. I can a map {_*2}, and the function operates on the Int held in the XorT. Is there a transformer or something similar that'll let us do something similar for XorT[Future, Throwable, Option[Int]] ? So, essentially something so I can avoid a nested map?
Rob Norris
@tpolecat
May 31 2016 20:09
Yeaaaah ... that's OptionT[XorT[Future, Throwable, ?], Int]
Which also lifts the Option effect to the top, so you get "fast fail" for None.
May or may not be what you're looking for but that's the immediate answer.
Ashic Mahtab
@ashic
May 31 2016 20:26
Thanks...could you possibly show a quick example of using it? For example:
val someFuture = Future {42}
val a: XorT[Future, Throwable, Int] = someFuture.attempT
val b: XorT[Future, Throwable, Option[Int]] or OptionT[XorT[Future, Throwable, ?], Int] = ???
b map {println(_) }
Ashic Mahtab
@ashic
May 31 2016 21:22

Hmmm...so I've managed to get this working with this:

val someFuture = Future{42}
val a = someFuture.attemptT
type FA[A] = XorT[Future, Throwable, A]
val b : FA[Int] = a
val c:  OptionT[FA, Int] = OptionT.liftF(b)
val d = c map {_ * 2}

Is there a way to work this without declaring the FA type? I noticed @tpolecat used a ? in the type signature, but I can't get it to compile.

Peter Neyens
@peterneyens
May 31 2016 21:29
The ? is using the kind projector compiler plugin.
Ashic Mahtab
@ashic
May 31 2016 21:32
@peterneyens ooh...I'm really enjoying this rabbit hole :smile:
Peter Neyens
@peterneyens
May 31 2016 21:35
These are analogous to your c with the FA type alias :
OptionT.liftF[XorT[Future, Throwable, ?], Int](a)  // using kind projector
OptionT.liftF[({type l[x] = XorT[Future, Throwable, x]})#l, Int](a) // type lambda
Pascal Voitot
@mandubian
May 31 2016 21:36
BTW, @tpolecat have you seen Onion idea to represent stacks of monadic types to replace MonadTransformers when manipulating Free? https://github.com/ProjectSeptemberInc/freek/blob/master/src/test/scala/AppSpec.scala#L346-L353
Rob Norris
@tpolecat
May 31 2016 21:37
No, I haven't gotten around to looking at it. I have a very large backlog.
Pascal Voitot
@mandubian
May 31 2016 21:39
like all of us :D
but it's a nice idea, a bit like Effects in Emm but without the issues linked to effects
Dale Wijnand
@dwijnand
May 31 2016 22:01
god there are references to ala carte everywhere..
Cody Allen
@ceedubs
May 31 2016 22:09
@dwijnand are you working on #1026?
Ashic Mahtab
@ashic
May 31 2016 22:09
@peterneyens thanks....both work. It's funny that IntelliJ can't understand the explicit types, but understands kind projector code just fine.
Dale Wijnand
@dwijnand
May 31 2016 22:15
@ceedubs Yeah I guess I am, except I'm also removing the ala carte imports
Cody Allen
@ceedubs
May 31 2016 22:16
@dwijnand oh. Why is that? I almost always use ala carte imports in my personal work, and we tend to at work also
Dale Wijnand
@dwijnand
May 31 2016 22:17
the motivation is you can't get it wrong if there's only one option
why do you always use ala carte?
Cody Allen
@ceedubs
May 31 2016 22:21
@dwijnand some teammates prefer ala carte imports because they make it easier to hone in on where imports are coming from. Separately, and this may not be quite as big of a deal with cats, I found that changing from implort Scalaz._ to ala carte imports on a project I used to work on reduced compile times by ~50%
Dale Wijnand
@dwijnand
May 31 2016 22:22
huh, I wonder why that is.
Cody Allen
@ceedubs
May 31 2016 22:22
import Scalaz._ increases the number of implicits in scope by a lot
and I don’t think that implicit search has a very sophisticated implementation
Dale Wijnand
@dwijnand
May 31 2016 22:23
wow, you think it's the meer churn of ignoring unrelated, unmatching typeclass instances in scope that slowed it?
Cody Allen
@ceedubs
May 31 2016 22:24
I don’t want to point fingers, because I know very little about this, but that was what I assumed
in a large file that uses typeclasses heavily you can also observe a noticeable performance degredation if you import Scalaz._ within intellij
Dale Wijnand
@dwijnand
May 31 2016 22:26
I see
alright
Cody Allen
@ceedubs
May 31 2016 22:26
I think this would be less of an isssue with cats, and I’m all for pointing people toward the uber import. But personally I’d prefer to still have the option of ala carte imports
InTheNow
@InTheNow
May 31 2016 22:29
Uber in cats, autoplugins in sbt... I'm right behind these as 95% of the time, it's a total win.
But for the 5%, and of course @ceedubs, having the "extra" option is awesome
Dale Wijnand
@dwijnand
May 31 2016 22:33
perhaps it could be an extra, "power" module, for the 5%
InTheNow
@InTheNow
May 31 2016 22:34
not just "power"... more likely "weird". But some form of opt out, yeah
and still an easy win for the 95%, of course
(may be "power" is better marketing ;) )
Adelbert Chang
@adelbertc
May 31 2016 22:39
how (in)correct would it to be to say that this ala carte import stuff matters only because we have orphan instances
Peter Neyens
@peterneyens
May 31 2016 22:46
I am not sure how the syntax imports are related with orphan instances ?
Adelbert Chang
@adelbertc
May 31 2016 22:47
i suppose syntax wouldnt be
but instances like
import cats.std.list._
would
Peter Neyens
@peterneyens
May 31 2016 22:49
Then I think you are right indeed.
Adelbert Chang
@adelbertc
May 31 2016 23:12
both having to use and explain to newcomers that the istance import is necessary for stdlib types but not for cats-specific types is a bit strange
i think this is one of the things scato worked hard to address
probably with other tradeoffs that im not aware of
that being said scalaz 8 i believe is going this direction https://github.com/scalaz/scalaz/commits/series/8.0.x