Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:56
    anatoliykmetyuk unassigned #8689
  • 08:56
    anatoliykmetyuk assigned #8689
  • 08:12
    anatoliykmetyuk edited #8689
  • 08:08
    anatoliykmetyuk commented #8689
  • 08:08
    anatoliykmetyuk commented #8685
  • 08:07
    anatoliykmetyuk edited #8689
  • 08:06
    anatoliykmetyuk synchronize #8689
  • 08:05
    anatoliykmetyuk closed #8685
  • 08:00
    nicolasstucki labeled #8680
  • 07:56
    nicolasstucki commented #8693
  • 07:54
    liufengyun assigned #8684
  • 07:54
    liufengyun unassigned #8684
  • 07:54
    nicolasstucki assigned #8693
  • 07:54
    nicolasstucki review_requested #8693
  • 07:54
    nicolasstucki opened #8693
  • 07:39
    ohze commented #8691
  • 07:34
    nicolasstucki review_requested #8692
  • 07:34
    nicolasstucki assigned #8692
  • 07:34
    nicolasstucki opened #8692
  • 07:29
    ohze edited #8691
Guillaume Martres
@smarter
One idea to get rid of Serializable showing up in type inference was to just add it as a parent of case clases after typechecking
since it's basically an implementation detail that no one cares about
Nicolas Rinaudo
@nrinaudo
people that work with Spark apparently care about it quite a bit
but yes, that'd work as well
Guillaume Martres
@smarter
they care about things extending Serializable
Nicolas Rinaudo
@nrinaudo
doesn't help with Product though
Guillaume Martres
@smarter
yeah I don't know what to do with Product
Nicolas Rinaudo
@nrinaudo
it's not a big deal, it's just very confusing for newcomers
Guillaume Martres
@smarter
might become irrelevant with the generic derivation stuff in dotty, or might not
agreed
hence why I think it's worth discussing on http://contributors.scala-lang.org/
Nicolas Rinaudo
@nrinaudo
and since I do a lot of work with beginners, it's something I have to explain again and agani, which is why I care
oh I absolutely intend to
(the generic derivation stuff in dotty is amazing to use, but looks absolutely nightmarish to write)
Guillaume Martres
@smarter
the idea so far is to have something really low-level in the compiler and higher-level shapeless-like things on top
Nicolas Rinaudo
@nrinaudo
that's what I've read, yes
Guillaume Martres
@smarter
Miles will be talking about that at scala days
Nicolas Rinaudo
@nrinaudo
oh cool
be honest - you guys designed match types specifically for him, right?
Guillaume Martres
@smarter
hah, kind of I guess
Nicolas Rinaudo
@nrinaudo

regarding enum, is there a syntax to define sum types within sum types? I was expecting:

  enum Foo {
    case Bar
    enum Baz {
      case Baz1
      case Baz2
    }
  }

But then this does not compile:

  val t: Foo = Foo.Baz.Baz1
Guillaume Martres
@smarter
no, that doesn't exist so far
Nicolas Rinaudo
@nrinaudo
ah. So ADTs declared via enum have a maximum depth of 1 at the moment
is there any plan to change that?
Guillaume Martres
@smarter
no one is working on that
or even suggested that
as far as I can tell
Nicolas Rinaudo
@nrinaudo
how upset do you think people would be if I suggested it?
Guillaume Martres
@smarter
shame on your family for ten generations
Nicolas Rinaudo
@nrinaudo
I assumed as much
Guillaume Martres
@smarter
seriously there's been so many discussions related to enum that I have no idea if this was discussed so far, so I'd say make a topic on https://contributors.scala-lang.org/ and see what happens
Nicolas Rinaudo
@nrinaudo
I'm being dense. Of course ADTs don't have a maximum depth of 1, since nothing prevents product types from having sum type fields
Guillaume Martres
@smarter
yeah
Nicolas Rinaudo
@nrinaudo
I don't know whether this even makes sense...
sorry, back to my cave!
Josh
@joshlemer
@nrinaudo I think the nested enums idea is nice and would be very useful
Nicolas Rinaudo
@nrinaudo
when? :)
Why not declare them at the "root"? isn't a bit like the difference between (A | B) | C and A | B | C?
Sébastien Doeraene
@sjrd
Nested enums are only useful if one uses the intermediate types; but since enums are defined in a way that tends to hide the types of specific cases, talking about the intermediate types does not make much sense.
Josh
@joshlemer
what about Paul Philips' SizeInfo example
enum SizeInfo {
  case Bounded(bound: Int)
  enum Atomic {
    case Infinite
    case Precise(size: Int)
  }
}
or
enum Ior[+A, +B] {
  case Both(left: A, right: B)
  enum Either[+A, +B] {
    case Left[+A, +B](value: A)
    case Right[+A, +B](value: B)
  }
}
Nicolas Rinaudo
@nrinaudo
The weird thing is, this compiles
Sébastien Doeraene
@sjrd
What do you expect the type of Left(5) to be? Should it be Either[Int, Nothing] or should it be Ior[Int, Nothing]? I argue that the former does not make sense, because Either sits at the same level as Both, but Both is not exposed as a type. And if the type of Left(5) is Ior anyway, then what good is Either?

The weird thing is, this compiles

Probably a missing check rather than an intentional thing.

Nicolas Rinaudo
@nrinaudo
Both is exposed as a type, isn't it?
Josh
@joshlemer
I thought it should be Either[Int, Nothing] and also thought Both would be exposed as a public type
Sébastien Doeraene
@sjrd
Kind of. It exists, but the type of Both(5, "foo") will be Ior[Int, String], not Both[Int, String], so you rarely observe Both. Why then should you observe Either?
Nicolas Rinaudo
@nrinaudo
new Both(5, "foo"): Ior.Both[Int, String] though