These are chat archives for typelevel/general

15th
Feb 2018
Alex Reisberg
@a-reisberg
Feb 15 17:02
Anyone here celebrates lunar new year? :D
Jose C
@jmcardon
Feb 15 17:02
I sorta am. GF is in China so I was video chatting during the celebrations since I couldn't travel there myself
Alex Reisberg
@a-reisberg
Feb 15 17:03
Happy new year to you :)
Jose C
@jmcardon
Feb 15 17:03
Thanks. I'm only along for the ride though.
Alex Reisberg
@a-reisberg
Feb 15 17:04
:)
Long Cao
@longcao
Feb 15 17:10
@a-reisberg o/
Alex Reisberg
@a-reisberg
Feb 15 17:12
What's "o/"? :)
Jose C
@jmcardon
Feb 15 17:12
o is a head, / is an arm
like raising your hand
Alex Reisberg
@a-reisberg
Feb 15 17:13
Whoa :). Never saw that before.
Long Cao
@longcao
Feb 15 17:14
yup
Alex Reisberg
@a-reisberg
Feb 15 17:15
@longcao Chúc mừng năm mới. :D
Long Cao
@longcao
Feb 15 17:15
@a-reisberg thanks! and you nailed it, I am indeed Vietnamese
Alex Reisberg
@a-reisberg
Feb 15 17:15
Well me too :P
Adelbert Chang
@adelbertc
Feb 15 17:44
happy lunar new year ya'll :D
Emily Pillmore
@emilypi
Feb 15 17:44
and happy lunar near year to you
Seth Tisue
@SethTisue
Feb 15 18:27
PR adding Either.left and Either.right methods to stdlib. opinions? seems like something Typelevel folks might have an opinion about. scala/scala#6328 please comment on the PR itself, I don’t always follow this room.
Emily Pillmore
@emilypi
Feb 15 18:28
I’m in favor. That’s very common usage
Seth Tisue
@SethTisue
Feb 15 18:31
is this something that Cats’s Either alternative used to have? and do scalaz folks use Either these days or their own Either-like thing?
Rob Norris
@tpolecat
Feb 15 18:31
We use Either. Scalaz still has \/.
Emily Pillmore
@emilypi
Feb 15 18:31
We use Disjunction, which is roughly the same
I’m pretty sure we have facilities in both libs for .left and .right.
Rob Norris
@tpolecat
Feb 15 18:33
Cats has 1.some but not 1.left. I think mouse provides that one.
Emily Pillmore
@emilypi
Feb 15 18:33
Oh? Interesting. I thought I saw a PR out for that.
Rob Norris
@tpolecat
Feb 15 18:34
Don't know. I think cats should have all those things built in but there's some disagreement about that.
Seth Tisue
@SethTisue
Feb 15 18:34
Left(3): Either[Int, String] vs Either.left[Int, String](3) seems like kind of a wash
Emily Pillmore
@emilypi
Feb 15 18:35
@tpolecat agreed
Rob Norris
@tpolecat
Feb 15 18:35
Ah you know, cats does bedazzle Either.
@ Either.left(1) 
res1: Either[Int, Nothing] = Left(1)
Emily Pillmore
@emilypi
Feb 15 18:35
~nice~
The types on that are preferable as well. I’m not sure if i agree that Either.left(1) should have the type Either[Int, A] as in the scala PR
Rob Norris
@tpolecat
Feb 15 18:36
The syntax I like is 1.left[String]
Having to repeat the inferable type when you specify the non-inferable one is kind of a grunt.
Emily Pillmore
@emilypi
Feb 15 18:38
:100:
Luka Jacobowitz
@LukaJCB
Feb 15 18:39
We have asLeft and asRight ;)
Rob Norris
@tpolecat
Feb 15 18:39
Aha!
Luka Jacobowitz
@LukaJCB
Feb 15 18:39
Also leftNel and rightNel
Rob Norris
@tpolecat
Feb 15 18:39
As an honorary maintainer I should probably know that. ;-)
Jose C
@jmcardon
Feb 15 18:39
I used to never import the full cats.implicits._ because it makes IJ completion take like a year
Luka Jacobowitz
@LukaJCB
Feb 15 18:40
We could do the partially applied trick for Either.left and Either.right, no?
Seth Tisue
@SethTisue
Feb 15 18:44

The syntax I like is 1.left[String]

adding extension methods on Any might be a harder sell… maybe not an impossible sell, I don’t know

Luka Jacobowitz
@LukaJCB
Feb 15 18:49
@SethTisue How about something like this:
object Either {
  def left[A]: FromLeftPartiallyApplied[A] = 
    new FromLeftPartiallyApplied[A]

  def right[A]: FromRightPartiallyApplied[A] = 
    new FromRightPartiallyApplied[A]
}
class FromLeftPartiallyApplied[A](val dummy: Boolean = true) 
  extends AnyVal {
    def apply[B](b: B): Either[B, A] = Left(b)
  }

class FromRighttPartiallyApplied[A](val dummy: Boolean = true) 
  extends AnyVal {
    def apply[B](b: B): Either [A, B] = Right(b)
  }
Then you can do Either.left[String](42) and get back a Either[String, Int]
Seth Tisue
@SethTisue
Feb 15 18:50
@LukaJCB interesting. you might make that suggestion on the PR
Luka Jacobowitz
@LukaJCB
Feb 15 18:50
Sure!
Seth Tisue
@SethTisue
Feb 15 18:50
as usual, Gitter is like tears in rain...
(by which I mean, whoever makes a final thumbs up/down decision on this is going to read the PR comments, not this room)
Luka Jacobowitz
@LukaJCB
Feb 15 18:52
Yeah fully agree
Adelbert Chang
@adelbertc
Feb 15 18:52
lol i like that, "tears in rain"
Mark Tomko
@mtomko
Feb 15 18:52
Can you use @tpolecat's trick described here https://gist.github.com/tpolecat/a5cb0dc9adeacc93f846835ed21c92d2 to avoid the dummy?
Martijn Hoekstra
@martijnhoekstra
Feb 15 18:52
it got me all melancholy-like
Mark Tomko
@mtomko
Feb 15 18:53
I need to test it out locally...
Luka Jacobowitz
@LukaJCB
Feb 15 18:54
@mtomko Why would you want that here? 🤔
Mark Tomko
@mtomko
Feb 15 18:54
maybe you wouldn't I'm just trying to figure out what the dummy is doing there
Eugene Platonov
@jozic
Feb 15 18:54
dummy is to satisfy anyval, no?
Mark Tomko
@mtomko
Feb 15 18:55
sorry, yeah, I'm slower at digesting this than you.
Luka Jacobowitz
@LukaJCB
Feb 15 18:56
Yeah, that dummy is needed sadly
Mark Tomko
@mtomko
Feb 15 18:58
now that I have it in an editor, I can see that :)
Luka Jacobowitz
@LukaJCB
Feb 15 18:59
:smile:
Sorry @mtomko I didn’t see your comment about avoiding dummy at first because it got squished under the expanded gist :D
Mark Tomko
@mtomko
Feb 15 19:00
yeah, is there a way to tell gitter not to import the gist?
I was cringing as I saw it explode into the room
Rob Norris
@tpolecat
Feb 15 19:03
@LukaJCB the last FromRighttPartiallyApplied in your paste has two t's
Luka Jacobowitz
@LukaJCB
Feb 15 19:03
Oops yeah
Rob Norris
@tpolecat
Feb 15 19:04
took me a sec to find. others may want to try it out
Luka Jacobowitz
@LukaJCB
Feb 15 19:04
thanks!
Jose C
@jmcardon
Feb 15 19:06
actually, now that that's come up, how do those anyval helpers actually work at runtime?
does it actually work as just a trick, or does it actually instantiate a class on the heap
Luka Jacobowitz
@LukaJCB
Feb 15 19:07
AFAIK it never allocates
Jose C
@jmcardon
Feb 15 19:07
If that's true, there's a lot of places I might use those in tsec instead of F[_], A
Luka Jacobowitz
@LukaJCB
Feb 15 19:08
Sounds like a good first issue for someone interested in contributing :smile:
Jose C
@jmcardon
Feb 15 19:09
Possibly. I finally have some time So I may raise an issue.
if it never allocates, it's super good for type inference
because F[_], A is so bad, ends up [Nothing, Nothing] a lot
without explicitly putting the type tehre
Luka Jacobowitz
@LukaJCB
Feb 15 19:10
Yeah it’s kinda dumb, I agree
Seth Tisue
@SethTisue
Feb 15 19:11
@mtomko to prevent Gitter from expanding a gist or other link, [link it](http://like.this)
Luka Jacobowitz
@LukaJCB
Feb 15 19:13
Also another funny thing about this is that you have to do it with a boolean, because if you try it with dummy: Unit = () the whole thing will explode :smile:
Jose C
@jmcardon
Feb 15 19:14
really?
what...
Rob Norris
@tpolecat
Feb 15 19:14
Yeah it crashes the compiler.
Jose C
@jmcardon
Feb 15 19:14
LOL
Luka Jacobowitz
@LukaJCB
Feb 15 19:15
scala/bug#9240
Emily Pillmore
@emilypi
Feb 15 19:24
They haven’t fixed that yet? Geez.
Rob Norris
@tpolecat
Feb 15 19:25
Aren't value types on the list to get axed?
Emily Pillmore
@emilypi
Feb 15 19:25
I know they still haven’t fixed
def f[a](a: a): a = a; val f.a = ()
Rob Norris
@tpolecat
Feb 15 19:25
They're so weird.
Emily Pillmore
@emilypi
Feb 15 19:25
Is it because they’re weird, or just that they never got them to work consistently?
I know the nested value classes problem was a huge deal breaker
Rob Norris
@tpolecat
Feb 15 19:27
They have all these weird rules, they create strange types, and they end up boxing so often they're not all that useful.
Emily Pillmore
@emilypi
Feb 15 19:28
S11101110111 (w/e) had a good article on that
Rob Norris
@tpolecat
Feb 15 19:28
Hopefully opaque types will work and value types can go away.
Seth Tisue
@SethTisue
Feb 15 19:32
+1
Paolo G. Giarrusso
@Blaisorblade
Feb 15 19:41
@LukaJCB isn't that fixed?
@tpolecat @SethTisue actually, soc convinced me one might want to reconsider, since Java value types are "around the corner"
Luka Jacobowitz
@LukaJCB
Feb 15 19:43
@Blaisorblade maybe, though in cats we have to consider 2.10.x :smile:
Paolo G. Giarrusso
@Blaisorblade
Feb 15 19:43
:-(
"around the corner" might mean still a couple of years (not sure), but waiting that sort of time seems reasonable before nontrivial language changes
Luka Jacobowitz
@LukaJCB
Feb 15 19:44
If Java value types work as well as opaque types, we could just compile opaque types to value classes, no?
Paolo G. Giarrusso
@Blaisorblade
Feb 15 19:45
Java value types seem the value classes we wanted
also, opaque types and value types solve almost orthogonal problems — there's one (big) usecase tackled by both
(Java) value types can have multiple members, be inlined, have value semantics, etc.
as a special case, they can be used for newtype
opaque types are types whose implementation is hidden, hopefully without performance impact (though this claim has open questions though)
and it's unclear if opaque types help with primitives?
in particular, opaque types can be used for newtype containing reference types with hidden constructors
@LukaJCB TLDR one could maybe just compile value classes to value types
Luka Jacobowitz
@LukaJCB
Feb 15 19:50
value classes to value types?
Rob Norris
@tpolecat
Feb 15 19:54
Historically it has been a bad bet to wait on the JVM.
Opaque types seem like a pretty small change. The representation is already supported by the language, it just requires some ceremony that can be simplified.
Luka Jacobowitz
@LukaJCB
Feb 15 19:56
Agreed, this is really important for the scala FP community and SIP-35 seems to be in a good shape
Seth Tisue
@SethTisue
Feb 15 20:03
@Blaisorblade I do think any opaque types proposal needs to take likely compatibility with likely JVM value-type changes into account, but I doubt that we should actually just sit and wait. if you think there are convincing reasons to wait, can you point me to where that argument is, on the record?
re “ waiting that sort of time seems reasonable”, I feel like we already waited a long long long time
Guillaume Martres
@smarter
Feb 15 20:08
we shouldn't sit and wait, we should actively engage with the JVM value type development process
Luka Jacobowitz
@LukaJCB
Feb 15 20:10
What’s the ETA though? 2020?
Guillaume Martres
@smarter
Feb 15 20:10
there's no ETA.
But consider that there's a new JVM every 6 month now
Rob Norris
@tpolecat
Feb 15 20:20
If and when valhalla appears it will be a big change to get it into Scala.
SIP-35 is simple and works now and will let us remove a lot of complexity, and do it now.
Guillaume Martres
@smarter
Feb 15 20:21
which is why we need to look into it now
Mark Tomko
@mtomko
Feb 15 20:21
the reified generics would save some trouble if they ever come
Rob Norris
@tpolecat
Feb 15 20:21
I don't like to pull out the graybeard stuff but I have been waiting for JVM features for more than 20 years and they're late 100% of the time.
Guillaume Martres
@smarter
Feb 15 20:21
and avoid inventing similar-but-slightly-different mechanisms
The pace at which the JVM is evolving is accelerating, and the development of Scala should take that into account
otherwise we'll paint ourselves into multidimensional corners
Rob Norris
@tpolecat
Feb 15 20:24
Haha we should be good at it by now ;-)
Guillaume Martres
@smarter
Feb 15 20:25
I guess that's kind of the fate of all programming languages :)
Paolo G. Giarrusso
@Blaisorblade
Feb 15 22:18
@SethTisue no strong opinion myself, hence we might want to consider
my bias is to optimize for less warts eventually, but luckily I just want to lay out tradeoffs
Paolo G. Giarrusso
@Blaisorblade
Feb 15 22:24
What I know: simon has been following the news from JVM devs (which aren't easy to read), and suggests (like @smarter) to engage with them. The most relevant convo should be https://www.reddit.com/r/scala/comments/7xgxbl/sip35_opaque_types/dua0ulc/?context=3, discussing http://cr.openjdk.java.net/~acorn/LWorldValueTypesFeb13.pdf.
Paolo G. Giarrusso
@Blaisorblade
Feb 15 22:40

@tpolecat I agreed that opaque types are simpler, but then Simon wrote

If you think about it, defining a method on an opaque types basically entails "define a method inside an implicit class inside a type companion alongside the opaque type inside a package object". That's seems incredibly ad-hoc to me

and that's not wrong

@mtomko not convinced there, Haskell doesn't reify generics by default
Greg Pfeil
@sellout
Feb 15 22:53
Isn’t there something in the Scala world like Greenkeeper? (And does anyone know of a Haskell one?)
Fabio Labella
@SystemFw
Feb 15 22:55
I think @tpolecat mentioned something along those lines a few days ago
an sbt plugin though, probably not as featureful
Rob Norris
@tpolecat
Feb 15 22:56
I don't know what Greenkeeper is.
Fabio Labella
@SystemFw
Feb 15 22:56
tells you when to update your deps
also runs your tests
and other stuff
iirc you mentioned an sbt plugin that tells you when to upgrade? did I misremember?
Greg Pfeil
@sellout
Feb 15 22:57
Yeah, Greenkeeper is for JS – it creates a pull request whenever your deps have a new release.
Rob Norris
@tpolecat
Feb 15 22:57
Oh, yeah. sbt-updates. No idea for Haskell
Fabio Labella
@SystemFw
Feb 15 22:57
ah, yeah
Luka Jacobowitz
@LukaJCB
Feb 15 22:58
WE should totally put that into the cats build
Adelbert Chang
@adelbertc
Feb 15 23:25
@sellout bump the pinned nixpkgs revision, or nix-channel --update if you dont pin? :trollface: