existential-type

Is there a shorthand for type variable 'm forSome { type m[O] <: UpperBound[O] }` in Scala?

﹥>﹥吖頭↗ 提交于 2021-02-05 08:09:30
问题 Problem: trait UpperBound[O] trait High[F[O] <: UpperBound[O]] def canEqual(that :Any) = that.isInstanceOf[High[_]] def high(h :High[_]) = ??? Does not compile, because scalac sees the _ type instead of a type constructor it expects. How to fix it, ideally without writing a novel? Original question (before edits in reply to Dmytro's answer) had: def canEqual(that :Any) = that.isInstanceOf[High[m forSome { type m[O] <: UpperBound[O] }]] def high(h :High[m forSome { type m[O] <: UpperBound[O] }

Aux-pattern usage compiles without inferring an appropriate type

人盡茶涼 提交于 2021-02-04 19:20:27
问题 Consider the following simple example involving Aux -pattern: sealed trait AdtBase abstract case class Foo(){ type T <: AdtBase } object Foo{ type Aux[TT] = Foo { type T = TT } } abstract case class Bar(){ type T <: AdtBase val foo: Foo.Aux[T] } object Bar { type Aux[TT] = Bar { type T = TT } def apply[TT <: AdtBase](f: Foo.Aux[TT]): Bar = new Bar() { override type T = TT override val foo: Foo.Aux[T] = f } } case class Baz(foo: Foo) def testBaz(baz: Baz) = Bar(baz.foo) //Compiles fine def

Understanding type arguments do not conform to class type parameter bounds error when using Higher kinded type parameter

你。 提交于 2021-01-29 21:55:54
问题 I am trying to understand why the following piece of code won't compile when I use a higher kinded type parameter for T in MyModel abstract class Model[M <: Model[M]] class MyModel[T] extends Model[MyModel[T]] class Bar[TModel <: Model[TModel]] object Foo extends App { new Bar[MyModel[_]] } But if i change it to new Bar[MyModel[Any]] it will compile. Why is this ? 回答1: Bar[MyModel[_]] is Bar[MyModel[X] forSome {type X}] . (It should not be confused neither with Bar[MyModel[X]] forSome {type X

Does GHC use dynamic dispatch with existential types?

让人想犯罪 __ 提交于 2021-01-27 09:54:58
问题 Does the following bit of code use dynamic dispatch as it's understood in C++ or Java? As I understand, at the last line, compiler cannot possibly know at compile time which implementation of (==) to call, yet the code compiles and produces correct results. Can someone please explain, what kind of implementation (vptr, for example) lies behind this? {-# LANGUAGE ExistentialQuantification #-} data Value = A Int data ForallFunc = forall a. Eq a => Forall (Value -> a) unpackA (A int) = int

Can I express a subclassing constraint?

帅比萌擦擦* 提交于 2021-01-27 05:09:16
问题 Still playing with existentials over constraints (just exploring this design space, I know it is considered bad by many Haskellers). See this question for more info. {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE ConstraintKinds #-} {-# Language TypeApplications #-} import GHC.Exts (Constraint) class Foo a where foo :: a -> Int class Foo a => Bar a where bar :: a -> String instance Foo Int where foo = id instance Bar Int where bar = show data Obj cls =

Difference between an undefined abstract type member and an existential type

╄→гoц情女王★ 提交于 2020-07-10 05:18:49
问题 Given an uninitialised abstract type member is =:= equal to an existential type implicitly[Undefined =:= x forSome { type x }] // ok then why there seems to be a difference between them in object O { type Undefined implicitly[Undefined =:= _] // ok def g[F[_]](fun: F[_] => F[_]) = ??? def h[F[_]](fun: F[Undefined] => F[Undefined]) = ??? g[List](l => List(42)) // ok h[List](l => List(42)) // error } Note how g compiles whilst h raises type mismatch error. Furthermore consider object O { type

Difference between an undefined abstract type member and an existential type

末鹿安然 提交于 2020-07-10 05:17:13
问题 Given an uninitialised abstract type member is =:= equal to an existential type implicitly[Undefined =:= x forSome { type x }] // ok then why there seems to be a difference between them in object O { type Undefined implicitly[Undefined =:= _] // ok def g[F[_]](fun: F[_] => F[_]) = ??? def h[F[_]](fun: F[Undefined] => F[Undefined]) = ??? g[List](l => List(42)) // ok h[List](l => List(42)) // error } Note how g compiles whilst h raises type mismatch error. Furthermore consider object O { type

How does one declare an abstract data container type in Haskell?

本秂侑毒 提交于 2020-06-25 07:54:05
问题 I read William Cook's "On Data Abstraction, Revisited", and re-read Ralf Laemmel's "The expression lemma" to try to understand how to apply the former paper's ideas in Haskell. So, I'm trying to understand how could you implement, e.g., a set union function, in Haskell without specifying the types? 回答1: There's multiple ways, depending on which version of "abstract data types" you're after. Concrete but opaque types : It's been a little while since I read Cook's lovely paper, but glancing

Why does scala require existential types to restrict a generic bound?

我们两清 提交于 2020-06-18 15:56:48
问题 With the following class hierarchy: trait Provider[A] { def get(): Seq[A] } abstract class ProviderImpl[A] extends Provider[A] { final override def get(): Seq[A] = Seq() } trait HasX { def getX: Int } trait RefinedProvider[A <: HasX] extends Provider[A] class TypedProviderImpl extends ProviderImpl[HasX] with RefinedProvider[HasX] I want to be able to do this: val provider: RefinedProvider[_] = new TypedProviderImpl() provider.get() map (_.getX) But it doesn't work, because the return type of