typeclass

In scala, how to make type class working for Aux pattern? - Part 2

随声附和 — Thu, 18 Feb 2021 19:46:28 +0000

In scala, how to make type class working for Aux pattern? - Part 2 随声附和 2021-02-19 03:46:28

问题

This is a follow up question of: In scala, how to make type class working for Aux pattern?

Considering the following example:

  trait Base {

    type Out
    def v: Out
  }

  object Base {

    type Aux[T] = Base { type Out = T }
    type Lt[T] = Base { type Out <: T }

    class ForH() extends Base {

      final type Out = HNil

      override def v: Out = HNil
    }

    object ForH extends ForH
  }

  trait TypeClasses {

    class TypeClass[B]

    def summon[B](b: B)(implicit ev: TypeClass[B]): TypeClass[B] = ev
  }

  object T1 extends TypeClasses {

    implicit def t1: TypeClass[Base.Aux[HNil]] = new TypeClass[Base.Aux[HNil]]

    implicit def t2: TypeClass[Int] = new TypeClass[Int]
  }

  object T2 extends TypeClasses {

    implicit def t1[T <: Base.Aux[HNil]]: TypeClass[T] = new TypeClass[T]
  }

  object T3 extends TypeClasses {

    implicit def t1[
        H <: HList,
        T <: Base.Lt[H]
    ]: TypeClass[T] = new TypeClass[T] {

      type HH = H
    }
  }

  object T4 extends TypeClasses {

    implicit def t1[
        H <: HList,
        T <: Base.Aux[H]
    ]: TypeClass[T] = new TypeClass[T] {

      type HH = H
    }
  }

  it("No Aux") {

    val v = 2

    T1.summon(v) // works
  }

  it("Aux1") {

    val v = new Base.ForH()

    T1.summon(v) // oops
    T1.summon(Base.ForH) // oops

    val v2 = new Base.ForH(): Base.Aux[HNil]
    T1.summon(v2) // works!
  }

  it("Aux2") {

    val v = new Base.ForH()

    T2.summon(v) // works
    T2.summon(Base.ForH) // works

    val v2 = new Base.ForH(): Base.Aux[HNil]
    T2.summon(v2) // works
  }

  it("Aux3") {

    val v = new Base.ForH()

    T3.summon(v) // oops
    T3.summon(Base.ForH) // oops

    val v2 = new Base.ForH(): Base.Aux[HNil]
    T3.summon(v2) // oops
  }

  it("Aux4") {

    val v = new Base.ForH()

    T4.summon(v) // oops
    T4.summon(Base.ForH) // oops

    val v2 = new Base.ForH(): Base.Aux[HNil]
    T4.summon(v2) // oops
  }

all implementations of TypeClasses contains an implicit scope of their underlying TypeClass, among them, the T1 is the most simple and specific definition for ForH, unfortunately it doesn't work. An improvement was proposed by @Dan Simon (in T2), it uses a type parameter to allow the spark compiler to discover ForH <:< Base.Aux[HNil]

Now imagine that I'd like to extend @Dan Simon's solution, such that the type class applies to all classes like ForH for different kinds of HList (a super trait of HNil). 2 natural extensions are in T3 & T4 respectively.

Unfortunately none of them works. The T4 can be explained by the fact that ForH <:< Aux[HList] is invalid, but T3 can't use this excuse. In addition, there is no way to improve it to compile successfully.

Why the type class summoning algorithm failed this case? And what should be done to make the type class pattern actually works?

回答1:

Again, T1.summon(v) doesn't compile because T1.t1 is not a candidate, manually resolved T1.summon(v)(T1.t1) doesn't compile.

For T3 and T4 T3.t1[HNil, Base.ForH], T4.t1[HNil, Base.ForH] would be a candidate

T3.summon(v)(T3.t1[HNil, Base.ForH]) // compiles
T4.summon(v)(T4.t1[HNil, Base.ForH]) // compiles

but the trouble is that H is inferred first and it's inferred to be Nothing but t1[Nothing, Base.ForH] doesn't satisfy type bounds.

So the trouble is not with implicit resolution algorithm, it's ok, the trouble is with type inference (and all we know that it's pretty weak in Scala).

You can prevent H to be inferred too fast as Nothing if you modify T3.t1, T4.t1

object T3 extends TypeClasses {    
  implicit def t1[
    H <: HList,
    T <: Base/*.Lt[H]*/
  ](implicit ev: T <:< Base.Lt[H]): TypeClass[T] = new TypeClass[T] {
    type HH = H
  }
}

object T4 extends TypeClasses { 
  implicit def t1[
    H <: HList,
    T <: Base/*.Aux[H]*/
  ](implicit ev: T <:< Base.Aux[H]): TypeClass[T] = new TypeClass[T] {
    type HH = H
  }
}

T3.summon(v) // compiles
T4.summon(v) // compiles

来源：https://stackoverflow.com/questions/65853961/in-scala-how-to-make-type-class-working-for-aux-pattern-part-2

标签

scala

typeclass

abstract-data-type

type-alias

scala-2.13

Any advantage of using type constructors in type classes?

末鹿安然 — Thu, 18 Feb 2021 14:01:16 +0000

Any advantage of using type constructors in type classes? 末鹿安然 2021-02-18 22:01:16

问题

Take for example the class Functor:

class Functor a
instance Functor Maybe

Here Maybe is a type constructor.

But we can do this in two other ways:

Firstly, using multi-parameter type classes:

class MultiFunctor a e
instance MultiFunctor (Maybe a) a

Secondly using type families:

class MonoFunctor a
instance MonoFunctor (Maybe a)

type family Element
type instance Element (Maybe a) a

Now there's one obvious advantage of the two latter methods, namely that it allows us to do things like this:

instance Text Char

Or:

instance Text
type instance Element Text Char

So we can work with monomorphic containers.

The second advantage is that we can make instances of types that don't have the type parameter as the final parameter. Lets say we make an Either style type but put the types the wrong way around:

data Silly t errorT = Silly t errorT

instance Functor Silly -- oh no we can't do this without a newtype wrapper

Whereas

instance MultiFunctor (Silly t errorT) t

works fine and

instance MonoFunctor (Silly t errorT)
type instance Element (Silly t errorT) t

is also good.

Given these flexibility advantages of only using complete types (not type signatures) in type class definitions, is there any reason to use the original style definition, assuming you're using GHC and don't mind using the extensions? That is, is there anything special you can do putting a type constructor, not just a full type in a type class that you can't do with multi-parameter type classes or type families?

回答1:

Your proposals ignore some rather important details about the existing Functor definition because you didn't work through the details of writing out what would happen with the class's member function.

class MultiFunctor a e where
    mfmap :: (e -> ??) -> a -> ????

instance MultiFunctor (Maybe a) a where
    mfmap = ???????

An important property of fmap at the moment is that its first argument can change types. fmap show :: (Functor f, Show a) => f a -> f String. You can't just throw that away, or you lose most of the value of fmap. So really, MultiFunctor would need to look more like...

class MultiFunctor s t a b | s -> a, t -> b, s b -> t, t a -> s where
    mfmap :: (a -> b) -> s -> t

instance (a ~ c, b ~ d) => MultiFunctor (Maybe a) (Maybe b) c d where
    mfmap _ Nothing = Nothing
    mfmap f (Just a) = Just (f a)

Note just how incredibly complicated this has become to try to make inference at least close to possible. All the functional dependencies are in place to allow instance selection without annotating types all over the place. (I may have missed a couple possible functional dependencies in there!) The instance itself grew some crazy type equality constraints to allow instance selection to be more reliable. And the worst part is - this still has worse properties for reasoning than fmap does.

Supposing my previous instance didn't exist, I could write an instance like this:

instance MultiFunctor (Maybe Int) (Maybe Int) Int Int where
    mfmap _ Nothing = Nothing
    mfmap f (Just a) = Just (if f a == a then a else f a * 2)

This is broken, of course - but it's broken in a new way that wasn't even possible before. A really important part of the definition of Functor is that the types a and b in fmap don't appear anywhere in the instance definition. Just looking at the class is enough to tell the programmer that the behavior of fmap cannot depend on the types a and b. You get that guarantee for free. You don't need to trust that instances were written correctly.

Because fmap gives you that guarantee for free, you don't even need to check both Functor laws when defining an instance. It's sufficient to check the law fmap id x == x. The second law comes along for free when the first law is proven. But with that broken mfmap I just provided, mfmap id x == x is true, even though the second law is not.

As the implementer of mfmap, you have more work to do to prove your implementation is correct. As a user of it, you have to put more trust in the implementation's correctness, since the type system can't guarantee as much.

If you work out more complete examples for the other systems, you find that they have just as many issues if you want to support the full functionality of fmap. And this is why they aren't really used. They add a lot of complexity for only a small gain in utility.

回答2:

Well, for one thing the traditional functor class is just much simpler. That alone is a valid reason to prefer it, even though this is Haskell and not Python. And it also represents the mathematical idea better of what a functor is supposed to be: a mapping from objects to objects (f :: *->*), with extra property (->Constraint) that each (forall (a::*) (b::*)) morphism (a->b) is lifted to a morphism on the corresponding object mapped to (-> f a->f b).
None of that can be seen very clearly in the * -> * -> Constraint version of the class, or its TypeFamilies equivalent.

On a more practical account, yes, there are also things you can only do with the (*->*)->Constraint version.

In particular, what this constraint guarantees you right away is that all Haskell types are valid objects you can put into the functor, whereas for MultiFunctor you need to check every possible contained type, one by one. Sometimes that's just not possible (or is it?), like when you're mapping over infinitely many types:

data Tough f a = Doable (f a)
               | Tough (f (Tough f (a, a)))

instance (Applicative f) = Semigroup (Tough f a) where
  Doable x <> Doable y = Tough . Doable $ (,)<$>x<*>y
  Tough xs <> Tough ys = Tough $ xs <> ys
  -- The following actually violates the semigroup associativity law. Hardly matters here I suppose...
  xs <> Doable y = xs <> Tough (Doable $ fmap twice y)
  Doable x <> ys = Tough (Doable $ fmap twice x) <> ys

twice x = (x,x)

Note that this uses the Applicative instance of f not just on the a type, but also on arbitrary tuples thereof. I can't see how you could express that with a MultiParamTypeClasses- or TypeFamilies-based applicative class. (It might be possible if you make Tough a suitable GADT, but without that... probably not.)

BTW, this example is perhaps not as useless as it may look – it basically expresses read-only vectors of length 2ⁿ in a monadic state.

回答3:

The expanded variant is indeed more flexible. It was used e.g. by Oleg Kiselyov to define restricted monads. Roughly, you can have

 class MN2 m a where
     ret2  :: a -> m a

 class (MN2 m a, MN2 m b) => MN3 m a b where
     bind2 :: m a -> (a -> m b) -> m b

allowing monad instances to be parametrized over a and b. This is useful because you can restrict those types to members of some other class:

import Data.Set as Set

instance MN2 Set.Set a where
    -- does not require Ord
    return = Set.singleton 

instance Prelude.Ord b => MN3 SMPlus a b where
    -- Set.union requires Ord
    m >>= f = Set.fold (Set.union . f) Set.empty m

Note than because of that Ord constraint, we are unable to define Monad Set.Set using unrestricted monads. Indeed, the monad class requires the monad to be usable at all types.

Also see: parameterized (indexed) monad.

来源：https://stackoverflow.com/questions/29463811/any-advantage-of-using-type-constructors-in-type-classes

标签

haskell

typeclass

Lift instance of class with a `MonadIO` type-variable to the transformed monad

ⅰ亾dé卋堺 — Wed, 10 Feb 2021 22:37:12 +0000

Lift instance of class with a `MonadIO` type-variable to the transformed monad ⅰ亾dé卋堺 2021-02-11 06:37:12

问题

As part of a program where I need to log data from monadic computations, I am trying to define a class to make this more convenient.

module Serial where
import Data.Int
import Data.IORef
import System.IO
import Control.Monad.Trans
import Foreign.Ptr
import Foreign.Marshal
import Foreign.Storable

class MonadIO m => Serial m a where
    get :: Handle -> m a
    put :: Handle -> a -> m ()

One of the things I'd like to be able to do is to define get and put in a 'higher' monad, since some data is inaccessible in IO. For simpler data, like instances of Storable, for example, IO is enough. I'd like to keep the basic instances in the 'lowest' possible monad, but allow the actions to be lifted to any 'higher' MonadIO instance.

instance (Serial m a, MonadIO (t m), MonadTrans t) 
    => Serial (t m) a where
       get = lift . get
       put h = lift . put h

instance Storable a => Serial IO a where
    get h = alloca (\ptr 
        -> hGetBuf h ptr (sizeOf (undefined :: a))
        >> peek ptr)
    put h a = with a (\ptr 
        -> hPutBuf h ptr $ sizeOf a)

The idea is to enable functions like

func :: Serial m a => Handle -> a -> m ()
func h a = put h (0::Int32) >> put h a

where an instance in IO can be combined with an instance in any MonadIO. However with my current code, GHC cannot deduce the instance for Serial m Int32. For the particular case of lifting IO this problem can be solved by liftIO, but if the base type is t IO that doesn't work anymore. I think this can be solved by overlapping instances, but I would like to avoid that if possible. Is there any way to achieve this?

回答1:

You can just write out the required extra constraint:

func :: (Serial m a, Serial m Int32) => Handle -> a -> m ()
func h a = put h (0::Int32) >> put h a

(I think this requires -XFlexibleContexts.)

If this makes the signatures unwieldy, you can group together constraints in a “constraint synonym class”:

class (Serial m a, Serial m Int32, Serial m Int64, ...)
       => StoSerial m a
instance (Serial m a, Serial m Int32, Serial m Int64, ...)
       => StoSerial m a

func :: StoSerial m a => Handle -> a -> m ()
func h a = put h (0::Int32) >> put h a

来源：https://stackoverflow.com/questions/64184067/lift-instance-of-class-with-a-monadio-type-variable-to-the-transformed-monad

标签

Lift instance of class with a `MonadIO` type-variable to the transformed monad

雨燕双飞 — Wed, 10 Feb 2021 22:36:49 +0000

Lift instance of class with a `MonadIO` type-variable to the transformed monad 雨燕双飞 2021-02-11 06:36:49

问题

As part of a program where I need to log data from monadic computations, I am trying to define a class to make this more convenient.

module Serial where
import Data.Int
import Data.IORef
import System.IO
import Control.Monad.Trans
import Foreign.Ptr
import Foreign.Marshal
import Foreign.Storable

class MonadIO m => Serial m a where
    get :: Handle -> m a
    put :: Handle -> a -> m ()

instance (Serial m a, MonadIO (t m), MonadTrans t) 
    => Serial (t m) a where
       get = lift . get
       put h = lift . put h

instance Storable a => Serial IO a where
    get h = alloca (\ptr 
        -> hGetBuf h ptr (sizeOf (undefined :: a))
        >> peek ptr)
    put h a = with a (\ptr 
        -> hPutBuf h ptr $ sizeOf a)

The idea is to enable functions like

func :: Serial m a => Handle -> a -> m ()
func h a = put h (0::Int32) >> put h a

回答1:

You can just write out the required extra constraint:

func :: (Serial m a, Serial m Int32) => Handle -> a -> m ()
func h a = put h (0::Int32) >> put h a

(I think this requires -XFlexibleContexts.)

If this makes the signatures unwieldy, you can group together constraints in a “constraint synonym class”:

class (Serial m a, Serial m Int32, Serial m Int64, ...)
       => StoSerial m a
instance (Serial m a, Serial m Int32, Serial m Int64, ...)
       => StoSerial m a

func :: StoSerial m a => Handle -> a -> m ()
func h a = put h (0::Int32) >> put h a

来源：https://stackoverflow.com/questions/64184067/lift-instance-of-class-with-a-monadio-type-variable-to-the-transformed-monad

标签

How to handle Option with an encoder typeclass in scala

人盡茶涼 — Wed, 10 Feb 2021 14:48:07 +0000

How to handle Option with an encoder typeclass in scala 人盡茶涼 2021-02-10 22:48:07

问题

I have a classic Encoder typeclass.

trait Encoder[A] {
  def encode(a: A): String
}

I have two questions

Question 1 : where does the divergence comes from :

[error] … diverging implicit expansion for type sbopt.Test.Encoder[None.type]
[error] starting with value stringEncoder in object Test
[error]   show(None)

implicit val stringEncoder = new Encoder[String] {
  override def encode(a: String): String = a
}
implicit def optionEncoder[A: Encoder]: Encoder[Option[A]] =
  (a: Option[A]) => {
    val encoderA = implicitly[Encoder[A]]
    a.fold("")(encoderA.encode)
  }
implicit def someEncoder[A: Encoder]: Encoder[Some[A]] =
  (a: Some[A]) => {
    val encoderA = implicitly[Encoder[A]]
    encoderA.encode(a.get)
  }
implicit def noneEncoder[A: Encoder]: Encoder[None.type] =
  (_: None.type) => ""

def show[A: Encoder](a: A) = println(implicitly[Encoder[A]].encode(a))

show(None)

Question 2 : I saw in circe that the Encoder is not contravariant. What are the pros and cons ?

trait Encoder[-A] {
  def encode(a: A): String
}

implicit val stringEncoder: Encoder[String] = (a: String) => a

implicit def optionEncoder[A: Encoder]: Encoder[Option[A]] =
  (a: Option[A]) => {
    val encoderA = implicitly[Encoder[A]]
    a.fold("")(encoderA.encode)
  }

def show[A: Encoder](a: A) = println(implicitly[Encoder[A]].encode(a))

show(Option("value"))
show(Some("value"))
show(None)

回答1:

Regarding 1.

Your definition of noneEncoder is not good. You have an extra context bound (and even extra type parameter).

With

implicit def noneEncoder/*[A: Encoder]*/: Encoder[None.type] =
  (_: None.type) => ""

it compiles:

show[Option[String]](None)
show[None.type](None)
show(None)

Your original definition of noneEncoder meant that you had an instance of Encoder for None.type provided you had an instance for some A (not constrained i.e. to be inferred). Normally this works if you have the only implicit (or at least the only higher-priority implicit). For example if there were only stringEncoder and original noneEncoder then show[None.type](None) and show(None) would compile.

Regarding 2.

PROS. With contravariant Encoder

trait Encoder[-A] {
  def encode(a: A): String
}

you can remove someEncoder and noneEncoder, optionEncoder will be enough

show(Some("a"))
show[Option[String]](Some("a"))
show[Option[String]](None)
show[None.type](None)
show(None)

CONS. Some people believe that contravariant type classes behave counterintuitively:

https://github.com/scala/bug/issues/2509

https://groups.google.com/g/scala-language/c/ZE83TvSWpT4/m/YiwJJLZRmlcJ

Maybe also relevant: In scala 2.13, how to use implicitly[value singleton type]?

来源：https://stackoverflow.com/questions/64027726/how-to-handle-option-with-an-encoder-typeclass-in-scala

标签

scala

typeclass

implicit

What is the correct way to define an already existing (e.g. in Prelude) operator between a user-defined type and an existing type?

我与影子孤独终老i — Tue, 09 Feb 2021 01:22:49 +0000

What is the correct way to define an already existing (e.g. in Prelude) operator between a user-defined type and an existing type? 我与影子孤独终老i 2021-02-09 09:22:49

问题

Suppose I have a custom type wrapping an existing type,

newtype T = T Int deriving Show

and suppose I want to be able to add up Ts, and that adding them up should result in adding the wrapped values up; I would do this via

instance Num T where
  (T t1) + (T t2) = T (t1 + t2)
  -- all other Num's methods = undefined

I think we are good so far. Please, tell me if there are major concerns up to this point.

Now let's suppose that I want to be able to multiply a T by an Int and that the result should be a T whose wrapping value is the former multiplied by the int; I would go for something like this:

instance Num T where
  (T t1) + (T t2) = T (t1 + t2)
  (T t) * k = T (t * k)
  -- all other Num's methods = undefined

which obviously doesn't work because class Num declares (*) :: a -> a -> a, thus requiring the two operands (and the result) to be all of the same type.

Even defining (*) as a free function poses a similar problem (i.e. (*) exists already in Prelude).

How could I deal with this?

As for the why of this question, I can device the following

in my program I want to use (Int,Int) for 2D vectors in a cartesian plane,
but I also use (Int,Int) for another unrelated thing,
therefore I have to disambiguate between the two, by using a newtype for at least one of them or, if use (Int,Int) for several other reasons, then why not making all of them newtypes wrapping (Int,Int)?
since newtype Vec2D = Vec2D (Int,Int) represents a vector in the plain, it makes sense to be able to do Vec2D (2,3) * 4 == Vec2D (8,12).

回答1:

Very similar examples have been asked often already, and the answer is that this is not a number type and therefore should not have a Num instance. What it actually is is a vector space type, accordingly you should define instead

{-# LANGUAGE TypeFamilies #-}

import Data.AdditiveGroup
import Data.VectorSpace

newtype T = T Int deriving Show

instance AdditiveGroup T where
  T t1 ^+^ T t2 = T $ t1 + t2
  zeroV = T 0
  negateV (T t) = T $ -t

instance VectorSpace T where
  type Scalar T = Int
  k *^ T t = T $ k * t

Then your T -> Int -> T operator is ^*, which is simply flip (*^).

That leads also to the more general what you should do when overloading a standard operator with a different meaning: just make it a separate definition. You don't even need to give it a different name, this can also be disambiguated using qualified module imports.

Just please don't instantiate classes incompletely, in particular not Num. This just leads to php-ish confusion when somebody uses a generic function with those types, it compiles just fine but then horribly breaks at runtime when the calling code expects Num semantics but the type fails to actually offer that.

来源：https://stackoverflow.com/questions/65641353/what-is-the-correct-way-to-define-an-already-existing-e-g-in-prelude-operator

标签

haskell

functional-programming

operator-overloading

typeclass

primitive-types

What is the correct way to define an already existing (e.g. in Prelude) operator between a user-defined type and an existing type?

我只是一个虾纸丫 — Tue, 09 Feb 2021 01:20:23 +0000

What is the correct way to define an already existing (e.g. in Prelude) operator between a user-defined type and an existing type? 我只是一个虾纸丫 2021-02-09 09:20:23

问题

Suppose I have a custom type wrapping an existing type,

newtype T = T Int deriving Show

and suppose I want to be able to add up Ts, and that adding them up should result in adding the wrapped values up; I would do this via

instance Num T where
  (T t1) + (T t2) = T (t1 + t2)
  -- all other Num's methods = undefined

I think we are good so far. Please, tell me if there are major concerns up to this point.

instance Num T where
  (T t1) + (T t2) = T (t1 + t2)
  (T t) * k = T (t * k)
  -- all other Num's methods = undefined

which obviously doesn't work because class Num declares (*) :: a -> a -> a, thus requiring the two operands (and the result) to be all of the same type.

Even defining (*) as a free function poses a similar problem (i.e. (*) exists already in Prelude).

How could I deal with this?

As for the why of this question, I can device the following

in my program I want to use (Int,Int) for 2D vectors in a cartesian plane,
but I also use (Int,Int) for another unrelated thing,
therefore I have to disambiguate between the two, by using a newtype for at least one of them or, if use (Int,Int) for several other reasons, then why not making all of them newtypes wrapping (Int,Int)?
since newtype Vec2D = Vec2D (Int,Int) represents a vector in the plain, it makes sense to be able to do Vec2D (2,3) * 4 == Vec2D (8,12).

回答1:

{-# LANGUAGE TypeFamilies #-}

import Data.AdditiveGroup
import Data.VectorSpace

newtype T = T Int deriving Show

instance AdditiveGroup T where
  T t1 ^+^ T t2 = T $ t1 + t2
  zeroV = T 0
  negateV (T t) = T $ -t

instance VectorSpace T where
  type Scalar T = Int
  k *^ T t = T $ k * t

Then your T -> Int -> T operator is ^*, which is simply flip (*^).

来源：https://stackoverflow.com/questions/65641353/what-is-the-correct-way-to-define-an-already-existing-e-g-in-prelude-operator

标签

haskell

functional-programming

operator-overloading

typeclass

primitive-types

What is the correct way to define an already existing (e.g. in Prelude) operator between a user-defined type and an existing type?

你。 — Tue, 09 Feb 2021 01:16:15 +0000

What is the correct way to define an already existing (e.g. in Prelude) operator between a user-defined type and an existing type? 你。 2021-02-09 09:16:15

问题

Suppose I have a custom type wrapping an existing type,

newtype T = T Int deriving Show

and suppose I want to be able to add up Ts, and that adding them up should result in adding the wrapped values up; I would do this via

instance Num T where
  (T t1) + (T t2) = T (t1 + t2)
  -- all other Num's methods = undefined

I think we are good so far. Please, tell me if there are major concerns up to this point.

instance Num T where
  (T t1) + (T t2) = T (t1 + t2)
  (T t) * k = T (t * k)
  -- all other Num's methods = undefined

which obviously doesn't work because class Num declares (*) :: a -> a -> a, thus requiring the two operands (and the result) to be all of the same type.

Even defining (*) as a free function poses a similar problem (i.e. (*) exists already in Prelude).

How could I deal with this?

As for the why of this question, I can device the following

in my program I want to use (Int,Int) for 2D vectors in a cartesian plane,
but I also use (Int,Int) for another unrelated thing,
therefore I have to disambiguate between the two, by using a newtype for at least one of them or, if use (Int,Int) for several other reasons, then why not making all of them newtypes wrapping (Int,Int)?
since newtype Vec2D = Vec2D (Int,Int) represents a vector in the plain, it makes sense to be able to do Vec2D (2,3) * 4 == Vec2D (8,12).

回答1:

{-# LANGUAGE TypeFamilies #-}

import Data.AdditiveGroup
import Data.VectorSpace

newtype T = T Int deriving Show

instance AdditiveGroup T where
  T t1 ^+^ T t2 = T $ t1 + t2
  zeroV = T 0
  negateV (T t) = T $ -t

instance VectorSpace T where
  type Scalar T = Int
  k *^ T t = T $ k * t

Then your T -> Int -> T operator is ^*, which is simply flip (*^).

来源：https://stackoverflow.com/questions/65641353/what-is-the-correct-way-to-define-an-already-existing-e-g-in-prelude-operator

标签

haskell

functional-programming

operator-overloading

typeclass

primitive-types

Why does this instance fail the coverage condition?

99封情书 — Mon, 08 Feb 2021 15:45:00 +0000

Why does this instance fail the coverage condition? 99封情书 2021-02-08 23:45:00

问题

Why does the following instance declaration fail the coverage condition in the absence of UndecidableInstances? It seems that if the functional dependency is satisfied in the context then it is satisfied in the new instance.

{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE UndecidableInstances #-}

class Foo a b | a -> b where

instance (Foo a b, Foo a' b') => Foo (a, a') (b, b') where

If I try to replicate the same thing with a type family there is no problem.

{-# LANGUAGE TypeFamilies #-}

type family Bar a

type instance Bar (a, b) = (Bar a, Bar b)

回答1:

I believe it's that constraints on instances aren't actually taken into account when selecting an instance. They become additional constraints to be proved at each use site, rather than limiting the applicability of the instance.

So your instance declaration is kind of equivalent to instance Foo (a, b) (c, d), which rather obviously fails the coverage condition.

Adding the (Foo a b, Foo a' b') only makes it so that some of the uses of the instance would result in "no such instance" errors, it doesn't actually change the types for which your instance will be selected.

回答2:

From the GHC docs:

The Coverage Condition. For each functional dependency, tvsleft -> tvsright, of the class, every type variable in S(tvsright) must appear in S(tvsleft), where S is the substitution mapping each type variable in the class declaration to the corresponding type in the instance declaration.

In your class you have a -> b, so tvsleft = a and tvsright = b. The substitution S maps a into S(a)=(a,a') and b into S(b)=(b,b').

So, we find type variables in S(tvsright)=S(b)=(b,b') (both b and b') which do not appear in S(tvsleft)=S(a)=(a,a'). Hence the coverage condition fails.

As @Ben said, the coverage condition does not take the context into account: only the instance head matters.

来源：https://stackoverflow.com/questions/26275940/why-does-this-instance-fail-the-coverage-condition

标签

haskell

typeclass

functional-dependencies

typeclasses without methods, used as constraints: do they get dictionaries?

爱⌒轻易说出口 — Mon, 08 Feb 2021 12:50:14 +0000

typeclasses without methods, used as constraints: do they get dictionaries? 爱⌒轻易说出口 2021-02-08 20:50:14

问题

If I'm using a typeclass to overload methods, that's implemented in 'dictionary passing style'. That is, the method gets an extra argument (that doesn't appear in surface Haskell); to resolve overloading the method looks up the dictionary by type of its 'proper' argument(s); and pulls a method implementation out of the dictionary. As described in this q, for example.

But what about typeclasses without methods? They can be used as constraints. Is there a dictionary for them? What does it contain?

For a specific example:

module M  where

class C a             -- no methods
                      -- no instances in module M
f :: C a => a -> Bool
f x = blah

There's no instances for C in this module, so if M gets imported into some other module (with C instances) how is f's dictionary lookup encoded?

The usual situation would be that class C has method(s); there's calls to them on RHS of the equation for f; so the wanted C a is encoded as a dictionary lookup for the method call.

Supplementary q's: (if anybody's still listening)

2a. For no-method typeclasses with superclass constraints: Where do the constraints go in the dictionary? A comment on a ticket from SPJ seems to suggest it's an argument to the dictionary's data constructor.

2b. For no-method typeclass instances with constraints: Again where do the constraints go in the dictionary?

Motivation

@Daniel in the comments is asking the motivation for these q's. Apart from just understanding compiler internals a bit better ...

GHC translates surface Haskell into an Internal Representation: System F_C, which has aot explicit type signatures at every function application. (Those applications must include applying to the dictionaries for a class.) I'm trying to understand where all the type-related components of class and instance decls go inside the dictionaries; to figure out how a term in F_C gets to an equivalent representation to the original Haskell. Then I don't understand how [typeclasses without methods] fit in. Because those classes cannot appear directly as terms in surface Haskell, but only as constraints. Then it must be dictionar(ies) for such a class that represent it at term level.

If you want to ask where this is going: there seems to be a limitation in F_C that it can't represent Functional Dependencies. Something to do with being unable to generate type-level evidence. Then I want to understand how that limitation arises/what about FunDeps can't be (or currently isn't) represented?

回答1:

Is there a dictionary for [typeclasses without methods]? What does it contain?

Yes, there is a dictionary with no fields.

Compare:

class Monoid a where
    mempty :: a
    mappend :: a -> a -> a
data DictMonoid a = DictMonoid a (a -> a -> a)

class C a
data DictC a = DictC

If M gets imported into some other module (with C instances) how is f's dictionary lookup encoded?

Type inference is used to determine what instance is needed when f is called; then GHC looks up that type in its collection of known instances (=known dictionaries).

One possible outcome of this process is that the instance we determine would be needed is polymorphic, and there is no fully polymorphic instance. Then the appropriate constraint (such as C a or C m or whatever) is attached to the inferred type of whatever term is calling f -- which is then compiled to a function which accepts a dictionary on f's behalf and passes it on.

For no-method typeclasses with superclass constraints: Where do the constraints go in the dictionary?

Somewhere. There's no observation you can make from the surface language to distinguish between different places. For example, consider:

class Semigroup a => Monoid a where mempty :: a
data DictMonoid1 a = DictMonoid1 (DictSemigroup a) a
data DictMonoid2 a = DictMonoid2 a (DictSemigroup a)

These are sort of the only two choices one could make for where to put the superclass' dictionary. But what difference could it possibly make?

Okay, but you asked about no-method typeclasses. But the answer is the same. You can't tell the order that superclass dictionaries are stored in.

class (A a, B a) => C a
data DictC1 a = DictC1 (DictA a) (DictB a)
data DictC2 a = DictC2 (DictB a) (DictA a)

What could you possibly do to tell the difference between these? Nothing.

For no-method typeclass instances with constraints: Again where do the constraints go in the dictionary?

Nowhere. They become arguments that the caller must supply to receive a dictionary. Particular fields of the supplied dictionary may be closed over by the new dictionary, of course. Example:

class Ord a where compare :: a -> a -> Ordering
data DictOrd a where DictOrd (a -> a -> Ordering)

instance (Ord a, Ord b) => Ord (a, b) where
    compare (a,b) (a',b') = compare a a' <> compare b b'
instanceOrdTuple :: DictOrd a -> DictOrd b -> DictOrd (a,b)
instanceOrdTuple (DictOrd comparea) (DictOrd compareb)
    = DictOrd $ \(a,b) (a',b') -> comparea a a' <> compareb b b'

Okay, but you asked about no-method typeclasses. But the answer is not significantly different. The instance's constraint dictionaries are not stored anywhere, just like before; the only difference is that now we can also be sure that even the fields of the supplied dictionaries are not closed over.

class A a where whateverA :: a -> Int
class B a where whateverB :: Int -> a
class C a
data DictA a = DictA (a -> Int)
data DictB a = DictB (Int -> a)
data DictC a = DictC

instance (A a, B a) => C [a]
instanceCList :: DictA a -> DictB a -> DictC [a]
instanceCList (DictA whateverAa) (DictB whateverBa) = DictC

The following commentary replies to an old version of the question.

There's no instances for C in this module, so the compiler can't discharge fs constraint.

It doesn't need to. f is compiled to a function which takes a dictionary as an argument; there's no need to create a dictionary to compile f, only to compile its callers.

The compiler can't discharge the C Char constraint arising from the equation for y. What does it do?

It reports that it can't discharge the C Char constraint and exits unsuccessfully. (This hardly even qualifies as a question -- just try it and see for yourself!)

来源：https://stackoverflow.com/questions/55358056/typeclasses-without-methods-used-as-constraints-do-they-get-dictionaries

标签

haskell

typeclass