These are chat archives for non/algebra

22nd
Jan 2015
Erik Osheim
@non
Jan 22 2015 11:57
@larsrh so this is a great question. i did open a bug about it: non/algebra#25
one thing that i don't have a great idea of right now -- how does the by-name RHS parameter get used in practice?
i knew that in theory it was useful for short-circuiting, e.g. for Monoid[Boolean]. is that it?
Lars Hupel
@larsrh
Jan 22 2015 12:01
Oh right, I forgot about #25. I will chime in there.
Right, that's one example
e.g. if you're foldMapping a large list to Boolean, you can exploit short-circuiting.
Erik Osheim
@non
Jan 22 2015 21:53
@johnynek hey, so if we were going to go the Lazy[A] route, would you be open to providing that type in algebra somewhere?
relatedly we might want to provide Lazily[L[_]] as well so that other "lazy-ish" types (shapeless.Lazy[A], Future[A], () => A, etc) can be used as well.
actually, Future[A] probably isn't appropriate here.
P. Oscar Boykin
@johnynek
Jan 22 2015 22:56
Sure. That's fine with me.
If we make it a trait, making an implicit to/from should be easy.
The typeclass thing may be okay, starts to feel like overengineered (not to mention, it looks like a lawless typeclass, which as you may know, some folks get nervous about).
Erik Osheim
@non
Jan 22 2015 22:58
well, i think Lazily[L[_]] is actually both a monad and a comonad, so there are plenty of laws if we want them (i think anyway)
but yeah, i mostly mention that because there are already several Lazy[_] implementations out there.
anyway thanks for helping talk through this.
P. Oscar Boykin
@johnynek
Jan 22 2015 23:00
sure, it is a monad and comonad, but does that define Lazily?
Miles Sabin
@milessabin
Jan 22 2015 23:00
Other things being equal I'd prefer a type class here.
P. Oscar Boykin
@johnynek
Jan 22 2015 23:01
fine by me. I'm not really super anti-lawless typeclass, I just prefer lawful ones.
Miles Sabin
@milessabin
Jan 22 2015 23:01
Well, what @non said, it's a monad and a comonad.
P. Oscar Boykin
@johnynek
Jan 22 2015 23:02
```scala
woops.
Miles Sabin
@milessabin
Jan 22 2015 23:02
I prefer to call them "axioms" ;-)
Erik Osheim
@non
Jan 22 2015 23:02
I'm willing to try to figure out a good way to specify strictness/laziness in laws too -- I feel like I read something about how to do that awhile ago.
P. Oscar Boykin
@johnynek
Jan 22 2015 23:03
so, we want something like trait Lazily[L[_]] { def get[T](l: L[T]): T } with the the property that Eq.eqv(get(l1), get(l1))
or maybe call it force or something.
@milessabin Axioms sound good.
Erik Osheim
@non
Jan 22 2015 23:05
right, and also things like def defer(t: => T): L[T] and def eval(t: T): L[T]
critically, you can put a T into L[T] (either lazily or strictly), and get a T out of L[T].
Miles Sabin
@milessabin
Jan 22 2015 23:06
Seeing as all we care about is that it's a (co)monad, why not (co)point or something friendlier and preferably Cats compliant?
Erik Osheim
@non
Jan 22 2015 23:06
well, we want two of them probably.
(at least, i want two of them)
i'm fine with point and copoint but we need a third name.
i dunno, am i being too fussy? do we only need def point(t: => T): L[T] ?
Miles Sabin
@milessabin
Jan 22 2015 23:08
Oh, you want a strict variant of point?
Erik Osheim
@non
Jan 22 2015 23:08
yes.
Miles Sabin
@milessabin
Jan 22 2015 23:08
Gotcha.
Erik Osheim
@non
Jan 22 2015 23:08
also, the names aren't as important here, since cats will have to provide its own Monad and Comonad instances anyway
Miles Sabin
@milessabin
Jan 22 2015 23:09
I guess, but consistency would be nice if it's not burdensome.
Erik Osheim
@non
Jan 22 2015 23:09
(in the sense that Future#apply gets used as point in Monad[Future].)
Miles Sabin
@milessabin
Jan 22 2015 23:09
Sure.
Does the strict variant gain us much here?