0

Here is a simple example of my intention:

  sealed trait Col[V] {

    trait Wrapper
  }

  object Col1 extends Col[Int]
  object Col2 extends Col[Double]

  type WOf[T <: Col[_] with Singleton] = T#Wrapper

this is an alternative (simpler & more generalisable) way of writing:

type WOf[T <: Col[_] with Singleton] = T match {
  case Col1.type => Col1.Wrapper
  case Col2.type => Col2.Wrapper
}

But the compiler won't let me:


[Error] 
***.scala:25:42: T is not a legal path
since it is not a concrete type

So what is the correct way to write the kind WOf?

UPDATE 1: I could speculate that Scala 3 can use this type constructor to represent an Eta-expanded polymorphic function of the following definition:

def wOf[T <: Col[_]](v: T): v.Wrapper = ???

I just don't know what it is, is there any reason Scala 3 will choose to make this kind definition only available for a very specific case?

tribbloid
  • 4,026
  • 14
  • 64
  • 103
  • 1
    In Scala 3 the 1st option is incorrect https://docs.scala-lang.org/scala3/reference/dropped-features/type-projection.html the 2nd option is correct if you write `case Col1.type => ...` instead of `case Col1 => ...` or introduce type aliases `type Col1 = Col1.type`. Also you can use type classes instead of match types https://stackoverflow.com/questions/50043630/what-does-dotty-offer-to-replace-type-projections https://users.scala-lang.org/t/converting-code-using-simple-type-projections-to-dotty/6516 – Dmytro Mitin Jan 23 '23 at 00:38
  • 1
    For a type class you can macro-generate instances https://stackoverflow.com/questions/74549477/scala3-crafting-types-through-metaprogramming – Dmytro Mitin Jan 23 '23 at 00:52
  • So it is not available by default. I wonder what kind of logical paradox has caused this decision ... – tribbloid Jan 23 '23 at 01:16
  • thanks lot Professor! corrected and add an update for more low-level justification – tribbloid Jan 23 '23 at 01:44
  • 1
    Well, general type projections were deprecated because of https://github.com/lampepfl/dotty/issues/1050 (there is a specific code sample there) https://contributors.scala-lang.org/t/proposal-to-remove-general-type-projection-from-the-language/2812 There is a dispute that maybe general type projections are still sound in many cases https://lptk.github.io/programming/2019/09/13/type-projection.html https://github.com/lampepfl/dotty-feature-requests/issues/14 (but it seems there is no rigorous proof in DOT) – Dmytro Mitin Jan 23 '23 at 03:46
  • I agree T#Wrapper is a type projection and is unsound, but (v: Singleton).Wrapper should just be a dependent type. I guess it was called "kind projector", not type projector for a reason – tribbloid Jan 23 '23 at 16:25
  • `v.Wrapper` is legal, no problem. – Dmytro Mitin Jan 23 '23 at 17:28
  • OK I guess higher kind support is never a commitment of the core logic. But surprisingly for this case Scala 3 & BSP has a buggy support, let me post my answer shortly – tribbloid Jan 23 '23 at 18:47

1 Answers1

0

Since this is a niche case of a new language, I would not expect to find example. So I end up asking BSP to generate it based on a variant of the official example:

https://docs.scala-lang.org/scala3/reference/new-types/polymorphic-function-types.html

class DependentPoly {

  sealed trait Col[V] {

    trait Wrapper
    val wrapper: Wrapper = ???
  }

  object Col1 extends Col[Int]

  object Col2 extends Col[Double]

  val polyFn = [C <: Col[?]] => (x: C) => x.wrapper
}

The type annotation generated by BSP is:

[C <: Col[?]] => (x: C) => x.Wrapper

Unfortunately it triggered a compiler bug at this moment:

https://github.com/lampepfl/dotty/issues/16756

So we'll have to wait for it to be fixed before using it anywhere

tribbloid
  • 4,026
  • 14
  • 64
  • 103
  • Bug reported for Scala 3.2.1 – tribbloid Jan 23 '23 at 18:52
  • Can't reproduce. The code compiles both in 3.2.1 https://scastie.scala-lang.org/E5PSNYnBTFu0nnqmyW6uOw and 3.2.2 https://scastie.scala-lang.org/EC5EMAJhRoOAR58qcHKjVA without errors (it's always a good idea to try the latest version). – Dmytro Mitin Jan 23 '23 at 19:01
  • 1
    Ah, ok, I see, the error is when you annotate the type explicitly https://scastie.scala-lang.org/nw2FfpUIRWqpSMiTI8LnJQ – Dmytro Mitin Jan 23 '23 at 19:05