To my letter on Haskell-2 with
>>Remark and question on the ambiguity problem
>>... "...Exploration of Design Space."
>>
>>... first argument approach *is practicable* ...
Dominic Duggan <[EMAIL PROTECTED]>
writes
>Matrix multiplication: * :: Matrix a -> Matrix b -> Matrix c
>
>does not satisfy the single-argument restriction, or even
>its generalization to an n-argument restriction.
>What happens if M1 :: Matrix Int and I type: M2 = M1 * M1 * M1
>
>I get: Mult (Matrix Int) (Matrix Int) a, Mult a (Matrix Int) b => b
>
>and type-checking fails due to ambiguity. You have to say:
>
>M2 = ((((M1 * M1) :: (Matrix Int)) * M1) :: (Matrix Int))
>
>[...]
As i understand next letter from Dominic, he ment the program
class Mult a b c where (*) :: a -> b -> c
instance...=> Mult (Matrix a) (Matrix b) (Matrix c) where (*) =...
f = let m1 =...:: Matrix Int in (m1*m1)*m1
Now, let it be something more definite:
class Mult a b c where mm :: a -> b -> c
instance Mult Int Int Int where mm a b = a*b
data Matrix a = Mt [[a]]
instance Mult a b c => Mult (Matrix a) (Matrix b) (Matrix c)
where
--for example
mm (Mt [[a]]) (Mt [[b]]) = Mt [[mm a b]]
f = let m1 = Mt [[0]] :: Matrix Int in mm m1 m1
Indeed, this yields an ambiguity in the result type.
Indeed, this ambiguity can be resolved by adding, say, `::Matrix Int'.
Now, recall the first-argument approach.
In my experience, i put for a class C a with the operation o
that
o :: Int has to become a -> Int
(`a' is for a sample element of a type)
o :: a ... a -> a
(first `a' for a sample, second is the real argument)
negate :: a -> a remains as it is
add :: a -> a -> a remains as it is
- if this can be called the first-argument approach.
Generalizing it to the multiparametric classes, i try
class Mult a b c where mm :: c -> a -> b -> c
--first `c' is for sample
instance Mult Int Int Int where mm _ a b = a*b
instance Mult a b c => Mult (Matrix a) (Matrix b) (Matrix c)
where
mm (Mt [[c]]) (Mt [[a]]) (Mt [[b]]) = Mt [[mm c a b]]
f = let m1 = Mt [[0]] :: Matrix Int in mm m1 m1 m1
And the types are resolved.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
