2014-06-20 114 views
8

爲了使Haskell的數字類型系統變得理智(r)替代,numeric-prelude的開發人員滑落並決定命名其所有類型類別C。除了使文檔完全混亂,這意味着我必須要完全限定的類型類的所有用途:如何定義類型同義詞

import qualified Algebra.Additive (C) 
import qualified Algebra.Ring (C) 
... 

newtype Foo a = Foo a 

instance (Algebra.Additive.C a) => Algebra.Additive.C (Foo a) where ... 

myadd :: (Algebra.Additive.C a) => a -> a -> a 
myadd a b = ... 

而且,由於NumericPrelude擁有細粒度的類型類,我通常要導入多個不同NumericPrelude模塊。

{-# LANGUAGE ConstraintKinds #-} 

module NPSynonyms (Additive) where 

import qualified Algebra.Additive (C) 

type Additive a = (Algebra.Additive.C a) 

,讓我做出理智的功能:我可以通過定義頂級約束同義詞簡化這一點

myadd :: (Additive a) => a -> a -> a 
myadd a b = ... 

然而,當我需要定義一個實例,我還是有(也)進口原裝NumericPrelude類:

{-# LANGUAGE ConstraintKinds #-} 

import NPSynonyms 
import Algebra.Additive (C) 

newtype Foo a = Foo a 

instance (Additive a) => Algebra.Additive.C (Foo a) where ... 

因此,而不是做一個Additive類型同類別Constraint,我會真的類似於定義一個類型類類型類的同義詞。在GHC 7.8中有沒有辦法做到這一點,還是有任何理智的選擇?

+10

我們是具體的。只有Henning Thielemann將他的所有類型'T'和他的所有類'C'命名。其他人都知道這很糟糕。 – Carl

+1

他*知道這很糟糕嗎?我可以嘗試說服他... – crockeea

+0

@Eric:不要打擾。他認爲這是有史以來最好的事情。 –

回答

5

你必須完全限定

不,不完全限定。考慮:

import qualified Algebra.Additive as Add 

myadd :: Add.C a => a -> a -> a 

這對我來說看起來相當可讀。

編輯:

而且考慮制定超和治療,作爲一個別名:

class (Add.C a, Ring.C a) => Num a where 
instance Num Int 
instance Num Word 
+0

是的,我意識到我可以在發佈後縮短資格,謝謝指出。雖然我沒有必要將類組合成一個新類,但是使用一個新類來解決'ConstraintKinds'的解決方案是否有優勢? – crockeea

+0

我現在沒有想到。 –