I found the following code snippet:
List[T] forSome { type T }
The forSome looks like a method, but my friend told me it's a keyword.
I googled it, but found few documents about forSome. What does it mean, and where can I get some documents about it?
The forSome keyword is used to define existential types in Scala. There's this Scala glossary page explaining what they are. I couldn't find a place in the Scala docs explaining them in detail, so here is a blog article I found on Google explaining how they are useful.
Update: you can find a precise definition of existential types in the Scala specification but it is quite dense.
To summarize some of the posts I linked to, existential types are useful when you want to operate on something but don't care about the details of the type in it. For example, you want to operate on arrays but don't care what kind of array:
def printFirst(x : Array[T] forSome {type T}) = println(x(0))
which you could also do with a type variable on the method:
def printFirst[T](x : Array[T]) = println(x(0))
but you may not want to add the type variable in some cases. You can also add a bound to the type variable:
def addToFirst(x : Array[T] forSome {type T <: Integer}) = x(0) + 1
Also see this blog post which is where I got this example from.
I don't know Scala, but your question picked up my interest and started Googling.
I found that in Scala's changelog:
"It is now possible to define existential types using the new keyword
forSome. An existential type has the form T forSome {Q} where Q is a
sequence of value and/or type declarations. "
Related
I've been digging into FP and everything that surrounds it, and I found the concept of kind projector written somewhere, without details nor explanations.
The only thing I found was this github project, and I'm starting to think if it was referring to this particular project, or to some generic concept in FP?
So, what is a kind projector? Why is it useful? (if possible, can you provide examples, resources, etc?)
This is indeed just a slightly awkward name for the specific plugin for the Scala compiler you linked to. I don't think it has any significance to itself, but it kind of fits its purpose.
What the plugin does is to provide an alternative syntax to Scala's usual workaround for type lambdas, which uses a language feature called type projections.
Say you wanted to implement Functor for Either. Now, Functor requires kind * -> *, whereas Either has kind * -> * -> *. So we need to first fix the first argument, and can then provide the implementation for the partially applied type constructor. The only way you can do this in "regular" Scala is this:
implicit def eitherIsFunctor[A]: Functor[{type λ[X] = Either[A, X]}#λ] = { ... }
where {type λ[X] = Either[A, X]} is an anonymous structural type, which is only immediately used to "project out" λ, the type we actually want. In Haskell, you could just say
instance Functor (Either a) where ...
where Either is partially applied (and a is quantified over automatically).
The plugin allows one to replace the projection with something that looks more like a usual partial application in Scala, namely Either[A, ?], instead of the hardly understandable {type λ[X] = Either[A, X]}#λ (and also provides general type lambdas, I think, always by converting them down to anonymous types and projections).
Scala 3 provides native type lambdas which are no longer based on type projection
A type lambda such as [X] =>> F[X] defines a function from types to
types.
For example,
trait Functor[F[_]]
new Functor[Either[String, Int]] {} // error
new Functor[({ type λ[X] = Either[String, X] })#λ] {} // Scala 2 type lambda based on type projection
new Functor[λ[X => Either[String, X]]] {} // kind projector type lambda
new Functor[Either[String, *]] {} // kind projector type lambda
new Functor[[X] =>> Either[String, X]] {} // Scala 3 type lambda
Also, there exists a proposal SIP: Underscore Syntax for Type Lambdas #5379 such that
Functor[Either[String, _]] // equivalent to Functor[[X] =>> Either[String, X]]
On page 136. page of the book "Scala in Depth" it is written:
But the following experiment suggests that here _ is just the same as any arbitrary type parameter T, so it is perhaps not an existential type.
scala> def foo[M[_]](f : M[Int]) = f
foo: [M[_]](f: M[Int])M[Int]
scala> def foo[M[T]](f : M[Int]) = f
foo: [M[T]](f: M[Int])M[Int]
Also note the section 4.4 of the Scala Language Specification below , this also suggests that _ is the same as T here.
Can someone explain what is going on here ?
M[_] in that context (i.e. as a type parameter declaration) is a higher kinded type (sometimes called a "type constructor"); as you say it's the same as M[X], with the _ just meaning we aren't going to reuse the name.
In a different context (e.g. as a type) the same syntax is sometimes used to mean an existential type M[X] forSome { type X }.
It's unfortunate and confusing that the syntax looks the same, but they're two different, unrelated features. If you're confused about which one a particular use of _ is, maybe check what the compiler/language feature warning is? In my own code I try to always write existential types explicitly (using forSome) to avoid this confusion, but this is just something I came up with, not a rule that libraries tend to follow.
What is the difference between List[T] forSome {type T} and List[T forSome {type T}]? How do I read them in "English"? How should I grok the forSome keyword? What are some practical uses of forSome? What are some useful practical and more complex than simple T forSome {type T} usages?
Attention: (Update 2016-12-08) The forSome keyword is very likely going away with Scala 2.13 or 2.14, according to Martin Odersky's talk on the ScalaX 2016. Replace it with path dependent types or with anonymous type attributes (A[_]). This is possible in most cases. If you have an edge case where it is not possible, refactor your code or loosen your type restrictions.
How to read "forSome" (in an informal way)
Usually when you use a generic API, the API guarantees you, that it will work with any type you provide (up to some given constraints). So when you use List[T], the List API guarantees you that it will work with any type T you provide.
With forSome (so called existentially quantified type parameters) it is the other way round. The API will provide a type (not you) and it guarantees you, it will work with this type it provided you. The semantics is, that a concrete object will give you something of type T. The same object will also accept the things it provided you. But no other object may work with these Ts and no other object can provide you with something of type T.
The idea of "existentially quantified" is: There exists (at least) one type T (in the implementation) to fulfill the contract of the API. But I won't tell you which type it is.
forSome can be read similar: For some types T the API contract holds true. But it is not necessary true for all types T. So when you provide some type T (instead of the one hidden in the implementation of the API), the compiler cannot guarantee that you got the right T. So it will throw a type error.
Applied to your example
So when you see List[T] forSome {type T} in an API, you can read it like this: The API will provide you with a List of some unknown type T. It will gladly accept this list back and it will work with it. But it won't tell you, what T is. But you know at least, that all elements of the list are of the same type T.
The second one is a little bit more tricky. Again the API will provide you with a List. And it will use some type T and not tell you what T is. But it is free to choose a different type for each element. A real world API would establish some constraints for T, so it can actually work with the elements of the list.
Conclusion
forSome is useful, when you write an API, where each object represents an implementation of the API. Each implementation will provide you with some objects and will accept these objects back. But you can neither mix objects from different implementations nor can you create the objects yourself. Instead you must always use the corresponding API functions to get some objects that will work with that API. forSome enables a very strict kind of encapsulation. You can read forSome in the following way:
The API contract folds true for some types. But you don't know for
which types it holds true. Hence you cannot provide you own type and
you cannot create your own objects. You have to use the ones provided
through the API that uses forSome.
This is quite informal and might even be wrong in some corner cases. But it should help you to grok the concept.
There are a lot of questions here, and most of them have been addressed pretty thoroughly in the answers linked in the comments above, so I'll respond to your more concrete first question.
There's no real meaningful difference between List[T] forSome { type T } and List[T forSome { type T }], but we can see a difference between the following two types:
class Foo[A]
type Outer = List[Foo[T]] forSome { type T }
type Inner = List[Foo[T] forSome { type T }]
We can read the first as "a list of foos of T, for some type T". There's a single T for the entire list. The second, on the other hand, can be read as "a list of foos, where each foo is of T for some T".
To put it another way, if we've got a list outer: Outer, we can say that "there exists some type T such that outer is a list of foos of T", where for a list of type Inner, we can only say that "for each element of the list, there exists some T such that that element is a foo of T". The latter is weaker—it tells us less about the list.
So, for example, if we have the following two lists:
val inner: Inner = List(new Foo[Char], new Foo[Int])
val outer: Outer = List(new Foo[Char], new Foo[Int])
The first will compile just fine—each element of the list is a Foo[T] for some T. The second won't compile, since there's not some T such that each element of the list is a Foo[T].
val mutator=HFactory.createMutator(keyspace,StringSerializer.get())
mutator.addInsertion("rahul", "user", HFactory.createColumn("birth_year", 1990,
StringSerializer.get(), LongSerializer.get()))//error in LongSerializer.get() as
mutator.execute()
I am using LongSerializer like above and i am getting the following error.
Description Resource Path Location Type
type mismatch; found : me.prettyprint.cassandra.serializers.LongSerializer
required: me.prettyprint.hector.api.Serializer[Any] Note: Long <: Any (and
me.prettyprint.cassandra.serializers.LongSerializer <:
me.prettyprint.cassandra.serializers.AbstractSerializer[Long]), but Java-defined trait
Serializer is invariant in type T. You may wish to investigate a wildcard type such as _
<: Any. (SLS 3.2.10) User.scala /winoria/app/models line 22 Scala Problem
Tell me the solution .
There are a couple of things happening here.
First, Java does not allow primitive types as generics, so Hector's LongSerializer is an AbstractSerializer[java.lang.Long]. However you are working in Scala, so you need an AbstractSerializer[scala.Long]. Depending on circumstances Scala's Long can either be a primitive long or java.lang.Long. The good news is Scala is smart enough to figure out what to use and when. What you need here is a little type coercion: LongSerializer.get().asInstanceOf[Serializer[Long]]
The other suspect is that you need me.prettyprint.hector.api.Serializer[Any]. It looks like whatever you are calling your method on is lacking proper type declarations. A sample of surrounding code would help diagnose this further.
Edit:
Thanks for posting the surrounding code. It looks like you have a type disagreement. createColumn[N, V] is inferred as createColumn[String, Int], because the 1990 argument you have provided is an Int. This gets converted to java.lang.Int, which is a class and does not have type conversions like primitives do. This is why you get the error "int cannot be cast to long".
val mutator = HFactory.createMutator(keyspace, StringSerializer.get)
mutator.addInsertion(
"rahul", "user",
HFactory.createColumn( // Either do: HFactory.createColumn[String, Long]
"birth_year", 1990L, // Or make sure the type is inferred as Long
StringSerializer.get,
// Coerce serializer to scala.Long
LongSerializer.get.asInstanceOf[Serializer[Long]]))
mutator.execute()
everyone . Please forgive me asking a stupid question on Scala.
Though I have been programming in Scala for about 2 years, I still find it hard to understand implicit usage. Let's take an example for discussion:
Array(1,2,3,4).map(x => x)
If you look up the scaladoc, you cant' find the method map on Array class. The reason that map can apply on Array(1,2,3,4) is that there is an implicit function implicit def intArrayOps (xs: Array[Int]): ArrayOps[Int] defined in scala.Predef.
However, there are two parameter lists, where the second one is written as implicit bf: CanBuildFrom[Array[T], B, That]). Now I wonder where the compiler finds a proper argument for type CanBuildFrom when applying map on Array(1,2,3,4).
The implicit resolution includes searching the companion object for the type of the implicit parameter as well as the companion objects for the type parameters of the implicit parameter. In the example above the signature of map is the following
def map[B, That](f: (Int) => B)(implicit bf: CanBuildFrom[Array[Int], B, That]): That
Since we have no type requirements for That we can ignore it for now. After we look in the local and container scopes and find no matching implicits, the next place to look for an implicit would be the companion object for CanBuildFrom. However it has no companion object. So we continue on and look in Array for an implicit. We find one in the form of
implicit def canBuildFrom[T](implicit m: ClassManifest[T]): CanBuildFrom[Array[_], T, Array[T]]
Since we have no type requirements and a matching implicit, "That" is forced to be of type Array[Int] and completes our typing.
This question is partially answered with other question on StackOverflow. Let me give a try to summarize them:
The first part you need to know is where the Scala compiler looks for implicits. You can find some more detail about CanBuildFrom here.
If you have understood what is mentioned in the answers about implicits ‣you should take a look to the construction of Scala Collections. Their inheritance-hierarchy is explained here and for List here. All of them are build up with Builders. This is explained in detail in a question about breakOut.
To round up your knowledge, you should know how to pimp the Collections. Also, this is explained on StackOverflow in this question.
Please note, the best answers on StackOverflow are summarized in the Scala-Tag-Wiki.