impredicativetypes

Why are higher rank types so fragile in Haskell

邮差的信 提交于 2020-01-12 07:28:47
问题 I was messing around with the runST function. Which has type (forall s. ST s a) -> a and it seems like trying to use it in any way that isn't directly applying without any indirection breaks it in pretty nasty ways. runST :: (forall s. ST s a) -> a const :: a -> b -> a so by substituting a in const for forall s. ST s a you should get the type of const runST const runST :: b -> (forall s. ST s a) -> a but instead GHC says that it can't match a with (forall s. ST s a) -> a but since a literally

Impredicative types vs. plain old subtyping

北城余情 提交于 2019-12-29 02:47:08
问题 A friend of mine posed a seemingly innocuous Scala language question last week that I didn't have a good answer to: whether there's an easy way to declare a collection of things belonging to some common typeclass. Of course there's no first-class notion of "typeclass" in Scala, so we have to think of this in terms of traits and context bounds (i.e. implicits). Concretely, given some trait T[_] representing a typeclass, and types A , B and C , with corresponding implicits in scope T[A] , T[B]

Practical Implications of runST vs unsafePerformIO

馋奶兔 提交于 2019-12-19 17:36:08
问题 I want something like f :: [forall m. (Mutable v) (PrimState m) r -> m ()] -> v r -> v r -- illegal signature f gs x = runST $ do y <- thaw x foldM_ (\_ g -> g y) undefined gs -- you get the idea unsafeFreeze y I'm essentially in the same position I was in this question where Vitus commented: [I]f you want keep polymorphic functions inside some structure, you need either specialized data type (e.g. newtype I = I (forall a. a -> a)) or ImpredicativeTypes. Also, see this question. The problem

Impredicative polymorphism in F#

北城以北 提交于 2019-12-06 18:55:45
问题 OCaml's Hindley-Milner type system does not allow for impredicative polymorphism (à la System-F), except through a somewhat recent extension for record types. The same applies to F#. It however is sometimes desirable to translate programs written with impredicative polymorphism (e.g. Coq) into such languages. The solution for Coq's extractor to OCaml is to (sparingly) use Obj.magic , which is a kind of universal unsafe cast. This works because in OCaml's runtime system, all values have the

Impredicative polymorphism in F#

删除回忆录丶 提交于 2019-12-05 00:20:04
OCaml's Hindley-Milner type system does not allow for impredicative polymorphism (à la System-F), except through a somewhat recent extension for record types. The same applies to F#. It however is sometimes desirable to translate programs written with impredicative polymorphism (e.g. Coq) into such languages. The solution for Coq's extractor to OCaml is to (sparingly) use Obj.magic , which is a kind of universal unsafe cast. This works because in OCaml's runtime system, all values have the same size regardless of their type (32 or 64 bits depending on architecture) the more sophisticated type

Why are higher rank types so fragile in Haskell

徘徊边缘 提交于 2019-12-03 12:27:09
I was messing around with the runST function. Which has type (forall s. ST s a) -> a and it seems like trying to use it in any way that isn't directly applying without any indirection breaks it in pretty nasty ways. runST :: (forall s. ST s a) -> a const :: a -> b -> a so by substituting a in const for forall s. ST s a you should get the type of const runST const runST :: b -> (forall s. ST s a) -> a but instead GHC says that it can't match a with (forall s. ST s a) -> a but since a literally means forall a. a which is satisfied by every type I don't see what is invalid about that. As it turns

Why can't the type of id be specialised to (forall a. a -> a) -> (forall b. b -> b)?

时光怂恿深爱的人放手 提交于 2019-12-03 05:36:08
问题 Take the humble identity function in Haskell, id :: forall a. a -> a Given that Haskell supposedly supports impredicative polymorphism, it seems reasonable that I should be able to "restrict" id to the type (forall a. a -> a) -> (forall b. b -> b) via type ascription. But this doesn't work: Prelude> id :: (forall a. a -> a) -> (forall b. b -> b) <interactive>:1:1: Couldn't match expected type `b -> b' with actual type `forall a. a -> a' Expected type: (forall a. a -> a) -> b -> b Actual type:

Impredicative types vs. plain old subtyping

Deadly 提交于 2019-11-28 16:48:07
A friend of mine posed a seemingly innocuous Scala language question last week that I didn't have a good answer to: whether there's an easy way to declare a collection of things belonging to some common typeclass. Of course there's no first-class notion of "typeclass" in Scala, so we have to think of this in terms of traits and context bounds (i.e. implicits). Concretely, given some trait T[_] representing a typeclass, and types A , B and C , with corresponding implicits in scope T[A] , T[B] and T[C] , we want to declare something like a List[T[a] forAll { type a }] , into which we can throw