Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:50
    smarter commented #8635
  • 00:30
    noti0na1 commented #8643
  • 00:29
    noti0na1 commented #8643
  • Mar 31 23:28
    smarter commented #8635
  • Mar 31 22:39
    felixmulder labeled #8645
  • Mar 31 22:39
    felixmulder assigned #8645
  • Mar 31 22:39
    felixmulder opened #8645
  • Mar 31 22:24
    odersky commented #8635
  • Mar 31 22:23
    odersky commented #8635
  • Mar 31 21:52
    odersky commented #8635
  • Mar 31 21:35
    smarter commented #8635
  • Mar 31 21:25
    felixmulder edited #8644
  • Mar 31 21:20
    felixmulder assigned #8644
  • Mar 31 21:20
    felixmulder labeled #8644
  • Mar 31 21:20
    felixmulder opened #8644
  • Mar 31 21:12
    odersky commented #8635
  • Mar 31 20:44
    odersky commented #8622
  • Mar 31 20:29
    odersky synchronize #8639
  • Mar 31 19:59
    smarter labeled #8643
  • Mar 31 19:59
    smarter opened #8643
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
Josh
@joshlemer
Because the entire point of the nested enums is, as you said, to use intermediate types
Sébastien Doeraene
@sjrd
Yes that would be the point, but it's weird that we refuse to infer the concrete cases, but we're fine with inferring the intermediate types. It's very inconsistent.
It would make a lot more sense if the apply methods were typed as their individual cases, like they are for current case classes.
But people don't want that, apparently, so...
Nicolas Rinaudo
@nrinaudo
Dotty doesn't really refuse to infer the internmediate types though, does it?
enum Foo {
  case Bar(i: Int)
  case Baz(b: Boolean)
}


scala> List(new Foo.Bar(1), new Foo.Baz(false))
val res3: List[Foo & Product & Serializable] = List(Bar(1), Baz(false))