Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 02 2017 08:33
    jbgi commented #15
  • Aug 02 2017 08:01
    aloiscochard commented #15
  • Aug 01 2017 22:07
    fommil commented #15
  • Aug 01 2017 22:07
    fommil closed #15
  • Aug 01 2017 21:36
    jbgi commented #15
  • Jul 31 2017 21:10
    fommil opened #15
  • Oct 17 2016 17:22
    TomasMikula opened #14
  • May 11 2016 07:41
    aloiscochard commented on 1bb646e
  • May 11 2016 06:10
    adelbertc commented on 1bb646e
  • May 11 2016 04:37
    aloiscochard edited #13
  • May 10 2016 20:43
    aloiscochard opened #13
  • May 10 2016 20:43

    aloiscochard on no-unapply

    Work around inference regressio… (compare)

  • May 10 2016 20:32

    aloiscochard on no-unapply

    Remove `Unapply`. Add `si2712fix-plugin` compiler… (compare)

  • May 10 2016 19:14

    aloiscochard on master

    Add `Compose`. Add `Endo`. (compare)

  • May 07 2016 05:30
    aloiscochard closed #12
  • May 07 2016 05:30
    aloiscochard commented #12
  • May 07 2016 05:30

    aloiscochard on master

    Update scalac and dependencies … (compare)

  • May 04 2016 04:13
    aloiscochard commented #12
  • Mar 22 2016 20:54
    jbgi opened #12
  • Feb 25 2016 04:57
    shajra-cogscale opened #11
Aloïs Cochard
@aloiscochard
great to see an active backlog here folks, I'm currently travelling for business in India (what a mindblowing country) so not sure when I'll have time to catch up, but I will!
Adelbert Chang
@adelbertc
:+1:
Aloïs Cochard
@aloiscochard
@jbgi @shajra @adelbertc I'm thinking about putting si2712fix-plugin and removing Unapply entirely
thoughts?
Adelbert Chang
@adelbertc
:+1:
i like it
Jean-Baptiste Giraudeau
@jbgi
:+1:
Jean-Baptiste Giraudeau
@jbgi
I'm not totally clear to what extent a fixed SI-2712 improve type inference. Does it mean that we could "fix" Functor.map signature? ( https://github.com/aloiscochard/scato/commit/5ac725dec8635b906896ff0eb2216543b5aae841#commitcomment-15674425 )
Aloïs Cochard
@aloiscochard
sadly no @jbgi, it does not affect inference at all, what it solve is really that higher order unification.
I've seen other proposals that works on adding multiple parameters group for implicits
which might help in some case, but not that particular one from what I can get
Jean-Baptiste Giraudeau
@jbgi
ok, thanks.
Sukant Hajra
@shajra
@aloiscochard so I'm confused about how the plugin relates to end-users.
just because Scato uses the plugin, that doesn't mean that Scato users will benefit from it, will it?
I'm probably mistaken on some basics.
Aloïs Cochard
@aloiscochard
I think it won't, but there is good hope for this to be in 2.12
btw, it does not compile :-/ seems I have to play with priorities like @xuwei-k did in scalaz/scalaz@fed9a20 for scalaz
Sukant Hajra
@shajra
what doesn't compile?
Aloïs Cochard
@aloiscochard
@shajra I just did what I suggested earlier in https://github.com/aloiscochard/scato/tree/feature/no-unapply
but I get error message, where the Monad => Applicative relationship is not resolved
I suspect it has to do with priorities, but I'm confused
oh okay found it
actually, it surprising it was compiling before
Aloïs Cochard
@aloiscochard
ah, no I think I got it.
so we are actually loosing some inference @jbgi
a rare case where it was actually working backwards
but I'm happy to give up this one and remove unapply ;)
this used to compile:
def pure[S, M[_], A](a: A)(implicit M: Monad[M]): StateT[S, M, A] = StateT(Thunk.map[S, M[(A, S)]](Nil)(s => (a, s).pure))
now it has to be: pure[M]
sounds like a regression
Adelbert Chang
@adelbertc
anyone still check in here? :P

i'll post my question anyways. so over in cats we're encoding the type class hierarchy the "old fashioned" way via inheritance. but this has led to issues with MTL-style programming

def foo[F[_], R, S](implicit R: MonadReader[F, R], S: MonadState[F, S]): F[Int] =
  for {
    int <- S.get
    char <- R.ask
  } yield false

fails to compile because (I'm guessing) it can't figure out if flatMap is from the MonadReader or MonadState. I vaguely recall the Scato encoding solving this.. is this true?

An alternative encoding was proposed: https://github.com/typelevel/cats/issues/1210#issuecomment-233425769 and it looks similar tot he Scato encoding to me
/cc @aloiscochard
Aloïs Cochard
@aloiscochard
yes still there @adelbertc, looking into it :-)
you are right, this is exactly it.
Adelbert Chang
@adelbertc
@aloiscochard gotcha
thanks for chiming in, appreciate it :-)
Aloïs Cochard
@aloiscochard
anytime :-)
Adelbert Chang
@adelbertc
@aloiscochard (and anyone else) - so the ambiguous implicits in the above example arise because both MonadReader and MonadState extends Monad so the compiler doesn't know which Monad instance to choose for the syntax. The Scato approach does trait MonadReader[F[_]] { self: Monad[F] => ... } and in order to make sure every MonadReader is a Monad, it does the implicit priority stuff to convert if/when necessary
effectively changing how type classes are encoded
i was wondering how terrible you think it would be (outside the context of scato/scalaz8, but in a world of the "usual" subtype encoding) to do something like trait Reader[F[_]] { self: monad[F] => ... } (i just renamed it), but without the implicit priority trick
users would then have to do def foo[F[_], R, S](implicit F: Monad[F], R: Reader[F, R], S: State[F, S]): F[Int] = ...
but it would solve the ambiguous implicits i think?
im mostly trying to get a better story around MTL style in Cats (or Scalaz 7 for that matter) which uses the subtyping approach
Aloïs Cochard
@aloiscochard
I just see your message now here, but I did already replied on the cats issue, let me know if you have any questions.
Alexandru Nedelcu
@alexandru
@aloiscochard so yea, I tried out your encoding. Seems nice, Scalaz 8 seems to be on a good path.
Aloïs Cochard
@aloiscochard
@alexandru thanks for your encouraging feedback man :)