Haskell 有什麼缺陷？

01-28

Haskell （GHC）在設計和實現上有什麼缺陷？會如何影響我們的使用？
雖然還有社區，學習曲線，配套設施等等方面的問題，但是希望答案能集中在語言(GHC)本身的設計和實現上

Monomorphism Restriction不能算是缺陷，現在GHC好像也默認了NoMonomorphismRestriction。這種問題本來就是怕引起特別多的重複計算，而把類型限定到單一類型上，但是這種重複計算出現的可能並不是特別多。

Prelude&> let foo x = let plus = (+1) in (plus 2, plus 3) Prelude&> :t foo foo :: (Num t2, Num t1) =&> t -&> (t1, t2)

GHC又不知道你想讓後面的是一種類型這是兩種。Haskll98默認是沒有這個選項了。引起這個問題的唯一原因就是Haskell已經把類型研究到極致了，你在其他語言（非函數式）里絕對見不到這樣的細節，因為其他語言的類型要明確標註，或者也是做了單態限定，要不4.4 + 3不把4轉為double怎麼計算？GHC單一同態限定恰恰把其他編譯器認為「理所當然」的過程暴露給你，讓你提供選擇。如果你把類型上下文全寫清楚來就不會有這樣的問題。

Prelude&> :set -XMonomorphismRestriction Prelude&> let foo x = let plus = (+1) in (plus 2, plus 3) Prelude&> :t foo foo :: Num t1 =&> t -&> (t1, t1)

這個問題是很subtle，是你不想給足夠的類型上下文導致的，相反我覺得這是Haskell類型系統設計的極為細緻一個體現。

1、Haskell本身採用ADT使得類型擴展比較困難。用Scala的話說就是Haskell里所有的data都是sealed，這對擴展性非常不利。不過已經有論文出現要解決這個問題了，因為GHC的設計者們發現解決這個問題跟解決類型上的open type family是何其相似的。

2、多參數的類型類重合問題

class C a b instance C Int a instance C a Int

問題來了，如果是C Int Int怎麼辦，Haskell有擴展任意選一個，我們無法參與，目前的GHC也不會報錯，好像連Warning都沒有，但是已經改進了，未來不知道會不會讓程序員指定匹配的優先順序。

3、Haskell並沒有被設計成依賴類型的語言（dependent type），但是卻想做跟那些語言相同的事，結果就是有時會搞得異常複雜。

{-# LANGUAGE KindSignatures,GADTs,TypeOperators,DataKinds #-} import GHC.TypeLits


data Vec a (n :: Nat) where

         Nil :: Vec a 0

         Cons :: a -&> Vec a n -&> Vec a (n + 1)
vhead :: (1 &<= n) =&> Vec a n -&> a

vhead (Cons a v) = a

vtail :: Vec a (n + 1) -&> Vec a n vtail (Cons x xs) = xs

你會得到下邊的錯誤，並且為了搞好這個問題你需要再同一大堆東西！這一大堆東西就是類型層面的證明，讓GHC相信，你寫的程序是可以deduce的，這實在是太讓人無力了。

Could not deduce (n1 ~ n) from the context ((n + 1) ~ (n1 + 1))

意思是說，從n1 = n 無法推出n + 1 = n1 + 1。學過定理證明的都懂，這是很好證明的，GHC目前用這裡的自然數無法自動證明這個，但目前GHC也在努力。而對於Agda

data Vec (A : Set) : Nat -&> Set where vnil : Vec A zero vcons : (n : Nat) &> A -&> Vec A n -&> Vec A (suc n)

tail : ? {A n} → Vec A (suc n) → Vec A n tail (_ ∷ xs) = xs

一切都是這麼稀鬆，不得不說Agda的設計可能更加趨於合理。未來的GHC可能會有解方程的機制，用SMT可以實現這個，不過目前還不行。

4、GHC的類型系統設計value與type沒有很好地整合在一起，雖然有DataKinds我想這多半是為的使用者考慮。如果設計得好將不會出現下邊的代碼：

type family EqBool a b where EqBool True True = True EqBool False False = True EqBool a b = False


type family EqOrdering a b where

  EqOrdering LT LT = True

  EqOrdering EQ EQ = True

  EqOrdering GT GT = True

  EqOrdering a  b  = False
type family EqList a b where

  EqList []        []        = True

  EqList (h1 : t1) (h2 : t2) = (h1 == h2)  (t1 == t2)

  EqList a          b          = False

type family EqMaybe a b where EqMaybe Nothing Nothing = True EqMaybe (Just x) (Just y) = x == y EqMaybe a b = False

這些代碼很傻地重複了值上的運算，並且在類型層面的無法使用類型類限定。我覺得偉大的GHC應該能避免寫這些東西，好的，有一個庫叫singleton在搞這個，我並不熟悉了，是一個賓夕法尼亞大學的博士在做。但是我並沒有系統地了解過DP，並不知道會有什麼樣的用處。

目前在我看來，Haskell語言日臻完美，GHC的bug主要集中在後端，而不是語法上，package主要就是一些支持的不完善的細節問題，就語言來說，可能Agda要更好，但是作為工程語言總是要有折衷的（Haskell的確是工程語言）。期待InjectiveTypeFamily（竊以為用這個可以解決ADT擴展的問題）還有OverloadedRecordField等一堆擴展。

如有問題歡迎討論

謝邀

我能理解的有Monomorphism restriction, 其他的我理解不了

默認non-strict是不是缺陷就見仁見智了, 這點的爭論也不少

cabal hell 太能折騰人了

GHC的運行時實現部分太噁心了，特別是：ghc/Linker.c at master · ghc/ghc · GitHub，手工把所有需要的C函數列了一坨，硬編碼鏈接進去。然後每次GHC、gcc、mingw版本變動，都要給這個破文件打一大坨補丁。也是為啥win32版ghc要自帶mingw，win32版ghc的bug之源。。。。

缺陷就是學起來太難。

最大的麻煩還是laziness導致的space leak吧，尤其是full laziness transform也可能會產生space leak，比如 https://www.reddit.com/r/haskell/comments/55xk4z/erratum_to_sharing_memory_leaks_and_conduit_and/。

缺陷其實挺多的。

Surprises of the Haskell module system (part 1)

初學者 length返回的是int 不是num 好麻煩、

fromIntegral (length [1,2,3,4])

同意學習太難的觀點，而且它的學習難是有自己的特點。

首先是概念太多，有時一份最簡單範例代碼，開頭各種擴展先引入7、8個。要想寫出生產型的代碼，Haskell可能是你需要掌握的概念最多的一門語言。

其次就是和流行的語言差異太大，其它語言裡面哪有聽說「類型」的類型也這麼多？