在Haskell中(至少在GHC v8.8.4中),在Num類中,NOT意味著在Eq類中:
$ ghci
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
λ>
λ> let { myEqualP :: Num a => a -> a -> Bool ; myEqualP x y = x=y ; }
<interactive>:6:60: 錯誤。
- Could not deduce (Eq a) arising from a use of ' =='
產生的。Numa
由type的簽名來約束:
myEqualP :: forall a. Num a => a -> a -> Bool。
at <interactive>:6:7-41。
Possible修復。
將(Eq a)添加到背景關系of中。
的type簽名為:
myEqualP :: forall a. Num a => a -> a -> Bool
- 在運算式:x == y
在'myEqualP'的方程式中:myEqualP x y = x == y
λ>。
這似乎是因為例如Num實體可以被定義為一些函式型別。
此外,如果我們防止ghci過度猜測整數字元的型別,它們就只有Num型別約束:
λ>
λ> :set -XNoMonomorphismRestriction。
λ>
λ> x=42
λ> :type x
x :: Num p => p
λ>
因此,像上面的x或42這樣的術語沒有理由具有可比性。
。但是,它們仍然碰巧是:
。
λ>
λ> y=43 假的。
λ>
有人能解釋一下這個明顯的悖論嗎?
uj5u.com熱心網友回復:
如果不使用Eq,就不能對整數字進行比較。但這也不是正在發生的事情。
在GHCi中,在NoMonomorphismRestriction下(現在的GHCi是默認的;不確定在GHC 8.8.4中)x = 42會產生一個x型別的變數forall p :: Num p => p.1
然后你做y = 43,這同樣導致變數y具有forall q的型別。Num q => q.2
然后你輸入x == y,GHCi必須進行評估,以便列印True或False。如果不為p和q選擇一個具體的型別(必須是相同的),就不能進行這種評估不能。每個型別都有自己的代碼來定義==,所以如果不決定使用哪個型別的代碼,就沒有辦法運行==的代碼。
然而x和y中的每一個都可以被使用作為Num中的任何型別(因為它們有一個定義,適用于所有的型別)4。所以我們只需使用(x :: Int) == y,編譯器將確定它應該使用Int的定義來處理==,或者x == (y :: Double)來使用Double的定義。我們甚至可以用不同的型別重復這樣做! 這些使用都沒有改變x或y的型別;我們只是使用它們每次支持的(許多)型別之一。
如果沒有defaulting的概念,一個光禿禿的x == y只會從編譯器中產生一個Ambiguous type variable錯誤。語言設計者認為這在數字字面中是非常常見的,也是非常令人討厭的(因為字面是多型的,但只要你對它們做任何操作,你就需要一個具體的型別)。所以他們引入了一些規則,即如果允許繼續編譯的話,一些模糊的型別變數應該被默認為具體型別。
因此,當你做x == y時,實際發生的情況是編譯器只是選擇Integer來用于x和y在該特定運算式中,因為你沒有給它足夠的資訊來確定任何特定型別(并且因為默認規則適用于這種情況)。Integer有一個Eq實體,所以它可以使用它,盡管x和y的最一般型別不包括Eq約束。如果不選擇something,它甚至不可能嘗試呼叫==(當然,它所選擇的 "something "必須是在Eq中,否則它仍然不會作業)。
如果你打開-Wtype-defaults(它包含在-Wall中),編譯器將在應用defaulting6時列印一個警告,這使得這個程序更加明顯。
1
1 forall p部分在標準的Haskell中是隱含的,因為all型別變數會在它們出現的型別運算式的開頭自動用forall引入。你必須打開擴展,才能手動寫入forall;要么是ExplicitForAll,只是為了能夠寫入forall,要么是許多擴展中的任何一個,它們實際上增加了使forall明確寫入的功能。
2 GHCi可能會再次選擇
p作為型別變數,而不是q。我只是用一個不同的來強調它們是不同的變數。
3 技術上來說,并不是每個型別都必須有不同的==,而是每個Eq實體。其中一些實體是多型的,所以它們適用于多個型別,但這只適用于有一些結構的型別(如Maybe a,等等)。基本型別如Int, Integer, Double, Char, Bool, 都有自己的實體,每個實體都有自己的==的代碼。
4在底層系統中,像
forall p. Num p => p這樣的型別實際上很像一個函式;一個將一個具體型別的Num實體作為引數的型別。為了得到一個具體的值,你必須首先對一個型別的Num實體 "應用函式",只有這樣你才能得到一個實際的值,它可以被列印出來,與其他東西比較,等等。在標準的Haskell中,這些實體引數總是被編譯器無形地傳遞著;一些擴展允許你更直接地操縱這個程序。
這就是為什么x == y在x和y是多型變數的情況下還能作業的根本原因。如果你必須明確地傳遞型別/實體引數,那么這里發生的事情將是顯而易見的,因為你必須手動地將x和y應用于某些東西并比較其結果。
5默認規則的要點是,如果一個模糊的型別變數上的約束條件是:
- 所有內置類
- 其中至少有一個是數字類(
Num,Floating,等等)
那么GHC將嘗試Integer,看看該型別是否檢查并允許所有其他約束被解決。如果不成功,它將嘗試Double,如果不成功then,它會報告一個錯誤。
你可以通過default宣告來設定它將嘗試的型別("默認默認 "為default(Integer, Double)),但是你不能自定義它將嘗試默認的條件,所以根據我的經驗,改變默認型別的作用有限。
然而,GHCi 配備了擴展的默認規則,這在解釋器中更為有用(因為它必須逐行進行型別推理,而不是一次性地對整個模塊進行推理)。你可以在編譯的代碼中用ExtendedDefaultRules擴展來打開它們(或者在GHCi中用NoExtendedDefaultRules來關閉它們),但同樣,根據我的經驗,這些選項都不是特別有用。解釋器和編譯器的行為不同是很煩人的,但是模塊一次編譯和行一次解釋之間的根本區別意味著切換其中一個的默認規則以使其與另一個的作業一致是更煩人的。(這也是為什么NoMonomorphismRestriction現在在解釋器中默認生效的原因;單態限制在編譯代碼中很好地實作了其目標,但在解釋器會話中幾乎總是錯誤的)。
6你也可以使用一個型別化的洞與asTypeOf幫助器相結合,讓GHC告訴你它正在為一個子運算式推斷出什么型別:
λ :t x
x :: Num p => p
λ :t y
y :: Num p => p
λ (x `asTypeOf` _) == y
<互動>:19:15: 錯誤。
- Found洞。_ :: IntegerIn第二個引數of'asTypeOf',即'_'
在第一個引數的'(==)',即'(x `asTypeOf` _)'
在運算式中。(x `asTypeOf` _) == y
- 相關的系結包括
it :: Bool (bound at <interactive> :19: 1)
有效的孔配合包括
x :: forall p. Num p => p
與x
(定義在<互動>:1:1)
it :: forall p. Num p => p
與它
(定義在<互動>:10:1)
y :: forall p. Num p => p
與y
(定義在<互動>:12:1)
你可以看到它告訴我們漂亮而簡單的發現洞。_ :: Integer,然后再繼續它喜歡給我們提供的所有關于錯誤的額外資訊。
一個型別化的漏洞(最簡單的形式)只是意味著在運算式的位置上寫上_。編譯器會在這樣的運算式上出錯,但它會試著給你提供關于你可以用什么來 "填空 "以使其編譯的資訊;最有用的是,它告訴你在該位置有效的東西的型別。
foo `asTypeOf` bar是一個古老的模式,用于添加一點型別資訊。它回傳foo,但是它限制了(這種特殊用法)它與bar的型別相同(bar的實際值完全沒有使用)。因此,如果你已經有一個型別為D的變數d,x `asTypeOf` d將是x作為Double的值。
這里我是在 "反向 "使用asTypeOf。我沒有用右邊的東西來約束左邊的東西的型別,而是在右邊放了一個洞(它可以有任何型別)。但是asTypeOf方便地確保它與x的型別相同,而不改變x在整個運算式中的使用方式(所以相同的型別推理仍然適用,包括默認,如果你把一個更大的運算式的一小部分抬出來,用詢問GHCi的型別,這并不總是如此。 t;尤其是:t x不會告訴我們Integer,而是Num p => p)。)
轉載請註明出處,本文鏈接:https://www.uj5u.com/yidong/316938.html
標籤:
上一篇:Haskell中的SBV解算器中沒有變數的瑣碎有理數問題
下一篇:如何用Shake來分配PTY?
