Is there any way, to get to the type of A from Some[A]?
type X = Some[Int]
type Y = ??? // what do I have to write here to get `Int`
I can define my own Option-type that allows this:
sealed trait Option[+A]
case object None extends Option[Nothing]
case class Some[+A](a: A) {
type Inner = A
}
and then use
type X = Some[Int]
type Y = X#Inner
Is this also possible somehow with the normal Scala Option type?
here is a solution that uses path dependent type to recover type from value:
trait IsOption[F]{
type T
def apply(f: F): Option[T]
}
object IsOption{
def apply[F](implicit isf: IsOption[F]) = isf
implicit def mk[A] = new IsOption[Option[A]]{
type T = A
def apply(f: Option[A]): Option[A] = f
}
}
def getInner[A](in:A)(implicit inner: IsOption[A]): Option[inner.T] = inner(in)
The answer is heavily inspired from this slide of a brilliant presentation: http://wheaties.github.io/Presentations/Scala-Dep-Types/dependent-types.html#/2/1
You have a function that receives an opaque A, but you recover the fact that it is an option and the inner type via the IsOption[A] implicit.
I appreciate that this is not exactly what you asked for, but when you use such type-dependent types. you need to have a concrete value from which you recover a type.
You can write a simple type function as follows:
scala> type X = Some[Int]
defined type alias X
scala> type F[H <: Option[A], A] = A
defined type alias F
scala> type Y = F[X, Int]
defined type alias Y
scala> implicitly[Y =:= Int]
res3: =:=[Y,Int] = <function1>
Without partial type parameter application / inference it's not very usefull, but it works...
Related
Assume the existence of the following types and method:
trait X[A <: X[A]]
case class C extends X[C]
def m(x: PartialFunction[X[_], Boolean])
I want to be able to create a PartialFunction to be passed into m.
A first attempt would be to write
val f: PartialFunction[X[_], Boolean] = {
case c: C => true
}
m(f)
This fails with type arguments [_$1] do not conform to trait X's type parameter bounds [A <: X[A]]. So, it seems we have to constraint X's type parameters.
A second attempt:
val f: PartialFunction[{type A <: X[A]}, Boolean] = {
case c: C => true
}
m(f)
This fails on the application of m because PartialFunction[AnyRef{type A <: X[this.A]},Boolean] <: PartialFunction[X[_],Boolean] is false.
Is there any way not involving casting that actually satisfies the compiler both on the definition of the partial function and on the application of m?
I'm not sure what exactly you want, but since you are using an existential type (in disguise of the _ syntax), this is how you can make that work:
val f: PartialFunction[X[A] forSome {type A <: X[A]}, Boolean] = {
case c : C => true
}
The _ syntax isn't good enough here, since you need to give the existential type the right upper bound. That is only possible with the more explicit forSome syntax.
What I find surprising, though, is that Scala accepts the declaration
def m(x: PartialFunction[X[_], Boolean])
in the first place. It seems weird that it even considers X[_] a well-formed type. This is short for X[A] forSome {type A <: Any}, which should not be a valid application of X, because it does not conform to the parameter bounds.
Not sure if that's what you wanted to achieve, but this is the working sequence:
trait X[A <: X[A]]
case class C extends X[C]
def m[T<:X[T]](x: PartialFunction[X[T], Boolean]) = print("yahoo!")
scala> def f[T<:X[T]]:PartialFunction[X[T], Boolean] = {
| case c: C => true
| }
f: [T <: X[T]]=> PartialFunction[X[T],Boolean]
scala> m(f)
yahoo!
Type macros are off.
However I have two important use cases that would have required them. The result is an important lost of extensibility in my application.
Both are dynamic compile time generation of a type given other types.
Basically i want to do something like (obviously not scala code but i think you'll get the idea) :
type T[U] = macro usecase1[U]
def usecase1[U]= U match {
case t if (t <:< Int) => String
case ... => ...
}
Second use case is :
type Remaining[A, B >: A] = macro ...
where for example
class C
trait T1 extends C
trait T2 extends C
type Remaining[C with T1 with T2, T2] is assigned to "C with T1" at compile time
(so the macro would have generated the subclass list, and generated a new type from the list without T2)
I didn't do it with macros so that are assumptions. I planned to do it now.. till i saw that type macro were dead.
Anyway, did anyone knows a trick to obtain such functionalities?
Thanks
The first use case is indeed implementable with implicits to some degree, as far as I understand it. Here's an example of how this might look like:
scala> trait Bound[A] {
| type Type
| }
defined trait Bound
scala> implicit val bound1 = new Bound[Int] { type Type = String }
bound1: Bound[Int]{type Type = String}
scala> implicit val bound2 = new Bound[String] { type Type = Double }
bound2: Bound[String]{type Type = Double}
scala> val tpe = implicitly[Bound[Int]]
tpe: Bound[Int] = $anon$1#2a6b3a99
scala> type U = tpe.Type
defined type alias U
But then:
scala> implicitly[U =:= String]
<console>:19: error: Cannot prove that U =:= String.
implicitly[U =:= String]
^
On the other hand:
scala> implicitly[bound1.Type =:= String]
res0: =:=[bound1.Type,String] = <function1>
Implicit resolution seems to be losing some types on the way. Not sure why, and how to work around that.
For the second use case, HLists immediately come to mind. Something like:
scala> trait Remaining[A <: HList, B] { type Result = Remove[A, B] }
defined trait Remaining
scala> new Remaining[C :: T1 :: T2 :: HNil, T2] {}
res5: Remaining[shapeless.::[C,shapeless.::[T1,shapeless.::[T2,shapeless.HNil]]],T2] = $anon$1#3072e54b
Not sure how to combine the resulting HList into a compound type though. Something like (pseudo-code):
trait Remaining[A <: HList, B] {
def produceType(
implicit ev0 : Remove.Aux[A, B, C],
ev1 : IsCons.Aux[C, H, T],
ev2 : LeftFolder[T, H, (T1, T2) => T1 with T2]) = ev2
// ^ Not real syntax, type-level function to combine/mix types
val tpe = produceType
type Result = tpe.Out
}
I already know that:
<: is the Scala syntax type constraint
while <:< is the type that leverage the Scala implicit to reach the type constrait
for example:
object Test {
// the function foo and bar can have the same effect
def foo[A](i:A)(implicit ev : A <:< java.io.Serializable) = i
foo(1) // compile error
foo("hi")
def bar[A <: java.io.Serializable](i:A) = i
bar(1) // compile error
bar("hi")
}
but I want to know when we need to use <: and <:< ?
and if we already have <:, why we need <:< ?
thanks!
The main difference between the two is, that the <: is a constraint on the type, while the <:< is a type for which the compiler has to find evidence, when used as an implicit parameter. What that means for our program is, that in the <: case, the type inferencer will try to find a type that satisfies this constraint. E.g.
def foo[A, B <: A](a: A, b: B) = (a,b)
scala> foo(1, List(1,2,3))
res1: (Any, List[Int]) = (1,List(1, 2, 3))
Here the inferencer finds that Int and List[Int] have the common super type Any, so it infers that for A to satisfy B <: A.
<:< is more restrictive, because the type inferencer runs before the implicit resolution. So the types are already fixed when the compiler tries to find the evidence. E.g.
def bar[A,B](a: A, b: B)(implicit ev: B <:< A) = (a,b)
scala> bar(1,1)
res2: (Int, Int) = (1,1)
scala> bar(1,List(1,2,3))
<console>:9: error: Cannot prove that List[Int] <:< Int.
bar(1,List(1,2,3))
^
1. def bar[A <: java.io.Serializable](i:A) = i
<: - guarantees that instance of i of type parameter A will be subtype of Serializable
2. def foo[A](i:A)(implicit ev : A <:< java.io.Serializable) = i
<:< - guarantees that execution context will contains implicit value (for ev paramenter) of type A what is subtype of Serializable.
This implicit defined in Predef.scala and for foo method and it is prove if instance of type parameter A is subtype of Serializable:
implicit def conforms[A]: A <:< A = singleton_<:<.asInstanceOf[A <:< A]
fictional case of using <:< operator:
class Boo[A](x: A) {
def get: A = x
def div(implicit ev : A <:< Double) = x / 2
def inc(implicit ev : A <:< Int) = x + 1
}
val a = new Boo("hi")
a.get // - OK
a.div // - compile time error String not subtype of Double
a.inc // - compile tile error String not subtype of Int
val b = new Boo(10.0)
b.get // - OK
b.div // - OK
b.inc // - compile time error Double not subtype of Int
val c = new Boo(10)
c.get // - OK
c.div // - compile time error Int not subtype of Double
c.inc // - OK
if we not call methods what not conform <:< condition than all compile and execute.
There are definitely differences between <: and <:<; here is my attempt at explaining which one you should pick.
Let's take two classes:
trait U
class V extends U
The type constraint <: is always used because it drives type inference. That's the only thing it can do: constrain the type on its left-hand side.
The constrained type has to be referenced somewhere, usually in the parameter list (or return type), as in:
def whatever[A <: U](p: A): List[A] = ???
That way, the compiler will throw an error if the input is not a subclass of U, and at the same time allow you to refer to the input's type by name for later use (for example in the return type). Note that if you don't have that second requirement, all this isn't necessary (with exceptions...), as in:
def whatever(p: U): String = ??? // this will obviously only accept T <: U
The Generalized Type Constraint <:< on the other hand, has two uses:
You can use it as an after-the-fact proof that some type was inferred. As in:
class List[+A] {
def sum(implicit ev: A =:= Int) = ???
}
You can create such a list of any type, but sum can only be called when you have the proof that A is actually Int.
You can use the above 'proof' as a way to infer even more types. This allows you to infer types in two steps instead of one.
For example, in the above List class, you could add a flatten method:
def flatten[B](implicit ev: A <:< List[B]): List[B]
This isn't just a proof, this is a way to grab that inner type B with A now fixed.
This can be used within the same method as well: imagine you want to write a utility sort function, and you want both the element type T and the collection type Coll. You could be tempted to write the following:
def sort[T, Coll <: Seq[T]](l: Coll): Coll
But T isn't constrained to be anything in there: it doesn't appear in the arguments nor output type. So T will end up as Nothing, or Any, or whatever the compiler wants, really (usually Nothing). But with this version:
def sort[T, Coll](l: Coll)(implicit ev: Coll <:< Seq[T]): Coll
Now T appears in the parameter's types. There will be two inference runs (one per parameter list): Coll will be inferred to whatever was given, and then, later on, an implicit will be looked for, and if found, T will be inferred with Coll now fixed. This essentially extracts the type parameter T from the previously-inferred Coll.
So essentially, <:< checks (and potentially infers) types as a side-effect of implicit resolution, so it can be used in different places / at different times than type parameter inference. When they happen to do the same thing, stick to <:.
After some thinking, I think it has some different.
for example:
object TestAgain {
class Test[A](a: A) {
def foo[A <: AnyRef] = a
def bar(implicit ev: A <:< AnyRef) = a
}
val test = new Test(1)
test.foo // return 1
test.bar // error: Cannot prove that Int <:< AnyRef.
}
this menas:
the scope of <: is just in the method param generic tpye scope foo[A <: AnyRef]. In the example, the method foo have it's generic tpye A, but not the A in class Test[A]
the scope of <:< , will first find the method's generic type, but the method bar have no param generic type, so it will find the Test[A]'s generic type.
so, I think it's the main difference.
I have some troubles having Scala to infer the right type from a type projection.
Consider the following:
trait Foo {
type X
}
trait Bar extends Foo {
type X = String
}
def baz[F <: Foo](x: F#X): Unit = ???
Then the following compiles fine:
val x: Foo#X = ???
baz(x)
But the following won't compile:
val x: Bar#X = ???
baz(x)
Scala sees the "underlying type String" for x, but has lost the information that x is a Bar#X. It works fine if I annotate the type:
baz[Bar](x)
Is there a way to make Scala infer the right type parameter for baz?
If not, what is the general answer that makes it impossible?
The program compiles by adding this implicit conversion in the context:
implicit def f(x: Bar#X): Foo#X = x
As this implicit conversion is correct for any F <: Foo, I wonder why the compiler does not do that by itself.
You can also:
trait Foo {
type X
}
trait Bar extends Foo {
type X = String
}
class BarImpl extends Bar{
def getX:X="hi"
}
def baz[F <: Foo, T <: F#X](clz:F, x: T): Unit = { println("baz worked!")}
val bi = new BarImpl
val x: Bar#X = bi.getX
baz(bi,x)
but:
def baz2[F <: Foo, T <: F#X](x: T): Unit = { println("baz2 failed!")}
baz2(x)
fails with:
test.scala:22: error: inferred type arguments [Nothing,java.lang.String] do not conform to method baz2's type parameter bounds [F <: this.Foo,T <: F#X]
baz2(x)
^
one error found
I think basically, F <: Foo tells the compiler that F has to be a subtype of Foo, but when it gets an X it doesn't know what class your particular X comes from. Your X is just a string, and doesn't maintain information pointing back to Bar.
Note that:
def baz3[F<: Foo](x : F#X) = {println("baz3 worked!")}
baz3[Bar]("hi")
Also works. The fact that you defined a val x:Bar#X=??? just means that ??? is restricted to whatever Bar#X might happen to be at compile time... the compiler knows Bar#X is String, so the type of x is just a String no different from any other String.
Below, the first case succeeds and the second fails. Why do I need an explicit evidence type / why does this Scala type bound fail? What's the type inferencer's particular limitation here in solving for A?
scala> implicit def view[A, C](xs: C)(implicit ev: C <:< Iterable[A]) = new { def bar = 0 }
view: [A, C](xs: C)(implicit ev: <:<[C,scala.collection.immutable.Iterable[A]])java.lang.Object{def bar: Int}
scala> view(List(1)) bar
res37: Int = 0
scala> implicit def view[A, C <: Seq[A]](xs: C) = new { def bar = 0 }
view: [A, C <: scala.collection.immutable.Seq[A]](xs: C)java.lang.Object{def bar: Int}
scala> view(List(1)) bar
<console>:149: error: inferred type arguments [Nothing,List[Int]] do not conform to method view's type parameter bounds [A,C <: scala.collection.immutable.Seq[A]]
view(List(1)) bar
^
Type inference unfortunately does not deal well with type parameters (such as C) that are bounded by (types that contain) other type parameters in the same type parameter list (here, A).
The version that encodes the constraint using an implicit argument does not suffer from this restriction since constraints imposed by implicits are solved separately from constraints imposed by type parameter bounds.
You can also avoid the cycle by splitting up the type of xs into the type constructor that abstracts over the collection (CC) and the (proper) type (A) that abstracts over its elements, like so:
scala> implicit def view[A, CC[x] <: Seq[x]](xs: CC[A]) = new { def bar = 0 }
view: [A, CC[x] <: Seq[x]](xs: CC[A])Object{def bar: Int}
scala> view(List(1)) bar
res0: Int = 0
For more details on types like CC, please see What is a higher kinded type in Scala?
I don't really know why this happens, although my hunch is it has to do with the variance of Seq's type parameter. I could get the following to work, though:
implicit def view[A, C[~] <: Seq[~] forSome { type ~ }](xs: C[A]) =
new { def bar = 0 }
Is there a reason why you want C—I mean, do you plan to use C inside the method? Because if not, why not just
implicit def view[A](xs: Seq[A]) = new { def bar = 0 }
?