53

Tôi đã đọc rằng hệ thống kiểu Scala bị suy yếu bởi khả năng tương tác Java và do đó không thể thực hiện một số quyền hạn giống như hệ thống kiểu của Haskell. Điều này có đúng không? Là điểm yếu bởi vì loại tẩy xoá, hoặc tôi là sai trong mọi cách? Sự khác biệt này có phải là lý do mà Scala không có typeclasses?Nhược điểm của hệ thống kiểu Scala so với Haskell?

+1

Bạn có thể muốn đọc nội dung này. http://lambda-the-ultimate.org/taxonomy/term/32 –

+4

Tôi khá chắc chắn rằng Haskell có ít nhất là xóa nhiều loại như Scala, cho những gì có giá trị. –

Trả lời

51

Sự khác biệt lớn là Scala không có suy luận kiểu toàn cầu Hindley-Milner và thay vào đó sử dụng một dạng suy luận kiểu cục bộ, yêu cầu bạn chỉ định các kiểu cho tham số phương thức và kiểu trả về cho các hàm quá tải hoặc đệ quy.

Điều này không được điều khiển bởi loại xóa hoặc các yêu cầu khác của JVM. Tất cả những khó khăn có thể xảy ra ở đây đều có thể khắc phục, và chỉ cần xem xét Jaskell - http://docs.codehaus.org/display/JASKELL/Home

Suy luận H-M không hoạt động trong ngữ cảnh hướng đối tượng. Cụ thể, khi sử dụng loại đa hình (trái ngược với tính đa hình đặc biệt của các lớp kiểu). Điều này là rất quan trọng cho interop mạnh mẽ với các thư viện Java khác, và (đến một mức độ thấp hơn) để có được tối ưu hóa tốt nhất có thể từ JVM.

Không thực sự hợp lệ khi nói rằng Haskell hoặc Scala có hệ thống kiểu mạnh hơn, chỉ là chúng khác nhau. Cả hai ngôn ngữ đều đang đẩy ranh giới cho lập trình dựa trên loại theo các hướng khác nhau, và mỗi ngôn ngữ có những điểm mạnh duy nhất khó sao chép trong ngôn ngữ kia.

+0

Chương 16 thể hiện các kiểu dữ liệu của Scala và khớp mẫu phát triển hệ thống suy luận kiểu theo kiểu H/M http: //www.scala -lang.org/docu/files/ScalaByExample.pdf – oluies

+4

"Suy luận của HM không hoạt động trong ngữ cảnh hướng đối tượng". Nhưng F # thực hiện H-M và có một mặt hướng đối tượng. –

+10

@Mauricio: Có, và OCaml là một ví dụ truy cập tốt hơn vì nó xâm nhập vào các loại lớp ... –

10

Scala không có rank-n types, mặc dù có thể là work around this limitation trong một số trường hợp nhất định.

+0

Trên một lưu ý liên quan, nó cũng không hỗ trợ impredicativity. –

13

một điểm thú vị khác cần xem xét là Scala hỗ trợ trực tiếp kiểu OO cổ điển. Có nghĩa là, có quan hệ loại phụ (ví dụ: Danh sách là một phân lớp của Seq). Và điều này làm cho suy luận kiểu phức tạp hơn. Thêm vào thực tế là bạn có thể kết hợp các đặc điểm trong Scala, có nghĩa là một kiểu nhất định có thể có nhiều quan hệ siêu kiểu (làm cho nó phức tạp hơn)

8

Tôi chỉ có ít kinh nghiệm với Haskell, nhưng điều rõ ràng nhất tôi lưu ý rằng hệ thống kiểu Scala khác với Haskell là kiểu suy luận.

Trong Scala, không có suy luận kiểu toàn cầu, bạn phải rõ ràng cho biết loại đối số hàm.

Ví dụ, trong Scala bạn cần phải viết này:

def add (x: Int, y: Int) = x + y 

thay vì

add x y = x + y 

Điều này có thể gây ra vấn đề khi bạn cần phiên bản chung của chức năng add làm việc với tất cả các loại kiểu có phương thức "+". Có một giải pháp cho việc này, nhưng nó sẽ nhận được nhiều tiết hơn. Nhưng trong sử dụng thực tế, tôi thấy hệ thống kiểu Scala đủ mạnh để sử dụng hàng ngày, và tôi gần như không bao giờ sử dụng những cách giải quyết chung này, có lẽ điều này là bởi vì tôi đến từ thế giới Java.

Và giới hạn khai báo rõ ràng loại đối số không cần thiết là điều xấu, bạn cần phải sao chép tài liệu.

23

Hệ thống kiểu Scala khác với hệ thống của Haskell, mặc dù các khái niệm của Scala đôi khi được lấy cảm hứng trực tiếp từ thế mạnh của Haskell và cộng đồng các nhà nghiên cứu và chuyên gia có hiểu biết của nó.

Tất nhiên, chạy trên máy ảo không chủ yếu dành cho lập trình hàm ở nơi đầu tiên sẽ tạo ra một số mối quan tâm về tính tương thích với các ngôn ngữ hiện có nhắm mục tiêu nền tảng này. Bởi vì hầu hết các lý do về các loại xảy ra tại thời gian biên dịch, các hạn chế của Java (như một ngôn ngữ và nền tảng) trong thời gian chạy là không có gì phải quan tâm (ngoại trừ Type Erasure, mặc dù chính xác lỗi này dường như làm cho việc tích hợp vào Hệ sinh thái Java liền mạch hơn).

Theo như tôi biết, "sự thỏa hiệp" duy nhất ở cấp hệ thống kiểu với Java là một cú pháp đặc biệt để xử lý các kiểu thô. Trong khi Scala thậm chí không cho phép các kiểu thô nữa, nó chấp nhận các tệp lớp Java cũ hơn với lỗi đó. Có thể bạn đã nhìn thấy mã như List[_] (hoặc dài hơn tương đương List[T] forSome { type T }). Đây là một tính năng tương thích với Java, nhưng được coi là một kiểu tồn tại bên trong và không làm suy yếu hệ thống kiểu.

Hệ thống kiểu của Scala không hỗ trợ type classes, mặc dù theo cách chi tiết hơn Haskell.Tôi khuyên bạn nên đọc bài báo này, điều này có thể tạo ra một ấn tượng khác về sức mạnh tương đối của hệ thống kiểu Scala (bảng ở trang 17 là một danh sách tốt đẹp về các khái niệm hệ thống kiểu rất mạnh).

Không nhất thiết liên quan đến sức mạnh của hệ thống kiểu là cách tiếp cận của trình biên dịch Scala và Haskell sử dụng để suy ra các loại, mặc dù nó có tác động đến cách viết mã. Có thuật toán suy luận kiểu mạnh mẽ có thể làm cho nó đáng giá để viết mã trừu tượng hơn (bạn có thể tự quyết định xem đó có phải là điều tốt trong mọi trường hợp) hay không.

Cuối cùng hệ thống kiểu Scala và Haskell được thúc đẩy bởi mong muốn cung cấp cho người dùng các công cụ tốt nhất để giải quyết vấn đề của họ, nhưng đã thực hiện các đường dẫn khác nhau đến mục tiêu đó.

+0

+1 để đề cập đến bảng đó. –

+3

loại tồn tại không hoàn toàn giống với loại thô. Ví dụ: Danh sách [_] không được coi là một loại tương đương với Danh sách khác [_] –

6

Họ cũng có thể giảm thiểu được không?

Xem trang của Oleg Kiselyov http://okmij.org/ftp/ ... Người ta có thể thực hiện phép tính lambda trong hệ thống kiểu của Haskell. Nếu Scala có thể làm điều đó, thì theo một nghĩa nào đó, hệ thống kiểu của Haskell và hệ thống kiểu của Scala tính toán cùng loại. Các câu hỏi là: Làm thế nào tự nhiên là một trong những khác? Làm thế nào thanh lịch là một trong những khác?

Các vấn đề liên quan