Có. Đây là lõi được tạo bằng GHC 7.4.2:
Foo.showInt :: GHC.Types.Int -> GHC.Base.String
[... attributes omitted ...]
Foo.showInt = GHC.Show.$fShowInt_$cshow
Như bạn có thể thấy, đây chỉ là tham chiếu trực tiếp đến GHC.Show.$fShowInt_$cshow
.
Hãy so sánh với những gì sẽ xảy ra nếu chúng ta loại bỏ các chữ ký kiểu để các suy ra loại Show a => a -> String
được sử dụng thay vì:
Foo.showInt
:: forall a_aop. GHC.Show.Show a_aop => a_aop -> GHC.Base.String
[... attributes omitted ...]
Foo.showInt =
\ (@ a_aot) ($dShow_aou :: GHC.Show.Show a_aot) (x_a9Z :: a_aot) ->
GHC.Show.show @ a_aot $dShow_aou x_a9Z
Ở đây, phải mất một cuộc tranh luận từ điển $dShow_aou
và nó sử dụng các chức năng accessor GHC.Show.show
nhìn lên chức năng thích hợp từ từ điển này trước khi áp dụng hàm kết quả cho đối số x_a9Z
.
Điều gì xảy ra trong trường hợp đầu tiên, ít nhất là về mặt khái niệm, vì loại bê tông được biết, GHC chèn tham chiếu trực tiếp vào từ điển thể hiện thích hợp thay vì dùng nó làm đối số. Sau đó, người truy cập, về cơ bản chỉ là một hãng thu âm, có thể được gạch chân và bạn để lại với một tham chiếu trực tiếp đến hàm thích hợp.
Nó thường sẽ làm, như được hiển thị bởi hammar, và đôi khi không. Do đó, câu hỏi tổng quát hơn là: "Những tình huống nào ngăn GHC tối ưu hóa tính không đồng nhất của dictionnary?" . Tôi biết một số tình huống liên quan đến phần mở rộng, nhưng IIRC cũng có những trường hợp như vậy trong Haskell 98, có thể với các hàm đệ quy đa hình. –