I need to match case while running select queries using outworkers.phantom dsl. When I use scala functions like toLowerCase
and(_.name.toLowerCase eqs name.toLowerCase)
I get this error
ambiguous implicit values:
both method neqAmbig1 in package shapeless of type [A]=> A =:!= A
and method neqAmbig2 in package shapeless of type [A]=> A =:!= A
match expected type com.outworkers.phantom.builder.ops.TokenTypes.ValueToken =:!= com.outworkers.phantom.builder.ops.TokenTypes.ValueToken
Any suggestions how to address this? Am new to scala.
Related
I am trying to do a match on a value based on its type, and there is a case where the expected type is a generic, like below:
def foo(bar: Matchable) = bar match
case (bar: Vector[String]) => println(bar.mkString(","))
However, I get the following warning at runtime:
the type test for Vector[String] cannot be checked at runtime
Why cannot it be checked and how could I overcome this?
I wrote this example
class TestMatch[T](private val t: T){
def test()(implicit ev: T <:< Option[Int]) = println(ev(t).get)
}
and a test for it
val tm = TestMatch(Some(10))
tm.test() //fine
val tm2 = TestMatch(10)
tm2.test() //compilation error
The question is who creates the implicit ev: T <:< Option[Int] when I invoke test method? I know I didn't. Maybe the compiler is aware of implicit <:< and know what to do with it.
Documenation of <:<was not quite clear
To constrain any abstract type T that's in scope in a method's
argument list (not just the method's own type parameters) simply add
an implicit argument of type T <:< U, where U is the required
upper bound; or for lower-bounds, use: L <:< T, where L is the
required lower bound.
Does it mean that the compiler will take the rest on itself? I just add the implicit ev: T1 <:< T2?
The first snippet compiles because of Predef.identity, which means you can always implicitly convert type T to type T (in this case Option[Int]). Otherwise, you would need to bring an implicit into scopre by yourself.
Does it mean that the compiler will take the rest on itself?
The compiler will search for an implicit in scope. If it finds a match, it will provide it, if it can't, you'll get a compilation error. With your example, the compiler finds that Some[Int] adheres to the implicit requirement of Some[Int] <:< Option[Int] as it is a direct subtype of Option[Int].
You can see this when compiling the code with scalac:
val tm: TestMatch[Some[Int]] = new TestMatch[Some[Int]](scala.Some.apply[Int](10));
tm.test()(scala.this.Predef.$conforms[Some[Int]]);
Where's for Int (your second example), there is no implicit in scope matching the requirement, and Int is not a subtype of Option[Int].
The compiler will try to look for implicit parameters in various predefined places. If it cant find them it will throw an error. This link might help: http://docs.scala-lang.org/tutorials/FAQ/finding-implicits.html
I'm practicing to use Scala reflection features, I get this result:
res46: reflect.runtime.universe.Type = scala.List[String]
How to test the result value see if it represents a List[String]?
In another word, how to test whether a universe.Type represents a specified ordinary Scala type?
import scala.reflect.runtime.universe._
val tpe: Type = ???
//type equivalence test (is tpe exactly List[String]?)
tpe =:= typeOf[List[String]]
//type conformance test (is tpe a subtype of List[String]?)
tpe <:< typeOf[List[String]]
I'm trying to set a view bound over a high-kinded type and I get an error message that I cannot understand.
$ scala -language:higherKinds
Welcome to Scala version 2.10.0 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_43).
Type in expressions to have them evaluated.
Type :help for more information.
scala> trait F[M[_]]
defined trait F
scala> def foo[M[_]](implicit m: M[_] => F[M]) = 42
foo: [M[_]](implicit m: M[_] => F[M])Int
scala> def bar[M[_] <% F[M]] = 42
<console>:8: error: type M takes type parameters
def bar[M[_] <% F[M]] = 42
^
Shouldn't bar compile to the same thing as foo? What am I missing?
Note that there's a subtle distinction between the M[_] in the type parameter list and the type M[_] (i.e., the role the M[_] plays in the function type in the implicit parameter list). The first is a type constructor parameter and the second is an existential type (see sections 4.4 and 3.2.10 of the Scala language specification for more information).
So for example we could replace the type constructor parameter M[_] with M[X] without changing the meaning, but this would be a syntax error in the latter case (which is shorthand instead for something like M[X] forSome { type X }).
The difference may be clearer in the following example (which compiles just fine):
scala> def bar[M[_], M_ <: M[_] <% F[M]] = 42
bar: [M[_], M_ <: M[_]](implicit evidence$1: M_ => F[M])Int
Here the first M[_] is a type constructor parameter, and the second (the upper bound on M_) is an existential type.
The Scala compiler could conceivably make M[_] <% F[M] work as you expect it to here—i.e., it could translate the type constructor parameter into an existential type in the type of the implicit parameter that it creates for the context bound—but that would require an extra little piece of compiler magic, and there's already enough of that to go around.
Can someone explain weird construction of structural type nested in generics:
implicit def Function1Functor[R]: Functor[({type λ[α]=(R) => α})#λ] =
new Functor[({type λ[α]=(R) => α})#λ] ....
This example comes from Scalaz library: Functor.scala
Why this construction is needed there? Wouldn't be simpler to write:
implicit def Function1Functor[R,A]: Functor[R =>A]
or
implicit def Function1Functor[R,A]: Functor[Function1[R,A]]
The signature of the Functor type constructor shows that it is parameterised with another, unary, type constructor F:
trait Functor[F[_]] extends InvariantFunctor[F]
Neither R => A nor Function1[R,A] are type constructors; they take no parameters.
However in:
type λ[α] = (R) => α
λ is a type constructor taking one parameter, α. (R is already defined in this context.)
The syntax ({type λ[α]=(R) => α})#λ is known as a type lambda. It is a syntactic trick allowing a type alias to be created inline and referred to via a projection, so the whole expression can be used where a type is required.