Table Of Links Bàn trái ABSTRACT Abstract 1 INTRODUCTION 1 Giới thiệu 2 DEPENDENTLY-TYPED OBJECT-ORIENTED PROGRAMMING 2 Lập trình định hướng đối tượng 3 CASE STUDY 3 Nghiên cứu trường hợp 4 DESIGN CONSTRAINTS AND SOLUTIONS 4 Thiết kế và giải pháp 5 FORMALIZATION 5 Formalization 6 DE/REFUNCTIONALIZATION 6/ Phục hồi chức năng 7 FUTURE WORK 7 Công việc tương lai 8 RELATED WORK 8 Công việc liên quan 9   CONCLUSION AND REFERENCES 9 Kết luận và tham chiếu Lập trình định hướng đối tượng tùy thuộc Các chương trình điển hình được viết bằng ngôn ngữ hướng đối tượng và chức năng có nhiều sự khác biệt.Chúng ta sẽ xem xét những sự khác biệt này xuất hiện như thế nào khi chúng ta xem xét các chương trình được viết theo phong cách hướng đối tượng. 2.1 Method Call Syntax and Self Parameters Các lập trình viên định hướng đối tượng quen thuộc với phương pháp gọi tổng hợp o.f(e) để kêu gọi một phương pháp f bằng cách dùng đối số e trên đối tượng o. Điều này đôi khi được trình bày dưới cái tên “tương tự chức năng gọi tổng hợp” như một định nghĩa thay thế cho cuộc gọi f(o, e), trong đó đối số đầu tiên của phương pháp f được gọi là tham số tự. Chúng ta lấy quan sát tổng hợp đơn giản này, xem làm thế nào chúng ta phải sửa đổi nó để thiết lập được nhập tùy thuộc, và làm thế nào điều này ảnh hưởng đến thiết kế của chúng ta về các loại codata. Như một điểm khởi đầu, chúng ta lấy bằng chứng Agda từ Hình 4. Trong bằng chứng đó, Booleans được định nghĩa là một kiểu dữ liệu, từ chối được định nghĩa là một chức năng không phụ thuộc từ Booleans đến Booleans, và neg_- ngược được định nghĩa là một chức năng phụ thuộc từ boolean x đến bằng chứng rằng x bằng neg(neg x). Trong hệ thống của chúng tôi, chúng tôi muốn thể hiện cả neg và neg_inverse mà không sử dụng các chức năng không phụ thuộc hoặc phụ thuộc. Đối với trường hợp không phụ thuộc, chúng tôi có thể thể thể hiện từ chối trực tiếp như một quan sát trên Booleans: def Bool.neg: Bool { True => False => True } Nếu chúng ta muốn thể hiện chức năng phụ thuộc neg_inverse như một quan sát trên Boolean theo cách tương tự, thì chúng ta phải thêm một tính năng, tự tham số. chúng ta có thể liên kết thuật ngữ mà chúng ta quan sát với một biến, mà chúng ta đã gọi ở đây là tự, và sử dụng biến này trong kiểu trả về của quan sát: def (self: Bool.neg_inverse: Eq(Bool, self, self.neg) { True => Refl(Bool, True), False => Refl(Bool, False) } Việc tái chức năng hóa các phương pháp này với các tham số tự quyết định đặc điểm đầu tiên của các loại codata phụ thuộc: các tham số tự quyết định trong các hủy diệt. Đó là các tham số tự trong các tuyên bố codata cung cấp cho chúng ta sức mạnh biểu cảm để đại diện đúng các giao diện và lớp xác minh theo phong cách hướng đối tượng. 2.2 Verified Interfaces and Classes Khi xác minh cấu trúc dữ liệu và thuật toán trong các ngôn ngữ được viết tùy thuộc, chúng ta có thể chọn giữa hai cách tiếp cận chung: xác minh nội tại và ngoại bộ. Sử dụng xác minh nội tại, chúng ta xác định cấu trúc dữ liệu hoặc thuật toán cùng với bằng chứng về tính chính xác của nó. Để xác minh nội tại cấu trúc dữ liệu, chúng ta thường thể hiện thuộc tính bằng cách sử dụng chỉ số kiểu, chẳng hạn như số lượng các yếu tố có trong một danh sách được lập chỉ mục chiều dài. Chúng ta có thể áp dụng một cách tiếp cận tương tự trong một phong cách hướng đối tượng bằng cách sử dụng các loại codata được lập chỉ mục [Thibodeau et al. 2016]. Sử dụng các chỉ số kiểu, chúng ta có thể đảm bảo rằng các quan sát chỉ được gọi trên các đối tượng đang ở trạng thái đúng. Chúng ta có thể thấy rằng, như thường lệ đối với phù hợp (co)mô hình phụ thuộc, phù hợp mô hình không thể thực hiện có thể phát sinh mà cần phải được đánh dấu là vô lý. nghĩa là, khi chúng ta thực hiện giao diện đệm cho bộ đệm trống chúng ta không cần phải thực hiện phương pháp đọc vì nó không bao giờ có thể được gọi. tuy nhiên, trong công việc này, chúng ta đi xa hơn các loại codata được lập chỉ mục, cho phép một phong cách xác minh nội tại. Chúng tôi cũng muốn hỗ trợ cách tiếp cận extrinsic, nơi chúng tôi muốn tách các đối tượng của chúng tôi khỏi các thông số kỹ thuật của chúng. Jacobs [1995] cung cấp cho chúng tôi một khái niệm ban đầu về cách đạt được mục tiêu đó. Ông đề xuất một hệ thống thông số kỹ thuật coalgebraic có thể được sử dụng để xác minh các lớp hướng đối tượng. Ví dụ, Hình 5a cho thấy một thông số kỹ thuật coalgebraic cho một bộ đệm một yếu tố thể hiện hành vi đọc liên tục (PR): Sau khi một yếu tố đã được lưu trữ, nó không thể được thay thế bằng phương pháp cửa hàng. Thay vào đó, người ta cần gọi phương pháp trống để làm trống buffer rõ ràng. Đọc từ buffer trống trả về lỗi. Thông số kỹ thuật này của buffer được đưa ra dưới dạng một tập hợp các tuyên bố tham chiếu đến trạng thái buffer s. Trong hệ thống của chúng tôi, chúng ta có thể thực hiện khái niệm này bằng cách sử dụng các tham số tự trên phá hoại, cho phép chúng ta thể hiện các thông số kỹ thuật như quan sát trên các loại codata. Loại codata trong Hình 5 xác định giao diện đã xác minh cho buffers đọc vĩnh viễn trong hệ thống của chúng ta. Tương tự như vậy, chúng ta có thể áp dụng phương pháp này cho các giao diện được xác minh như chức năng hoặc monad. 2.3 Dependent Functions Không giống như hầu hết các lý thuyết kiểu phụ thuộc khác, các chức năng phụ thuộc kiểu Π không phải là một phần của lý thuyết cốt lõi của chúng tôi, nhưng có thể được định nghĩa trong một thư viện. Chúng tôi đề xuất rằng cả hai chức năng phụ thuộc và không phụ thuộc nên được người dùng xác định thay vì tích hợp. các nhà thiết kế của Java quyết định làm theo cách tiếp cận này khi họ giới thiệu trừu tượng lambda như các ví dụ của giao diện chức năng [Goetz et al. 2014; Setzer 2003] trong Java 8. Ngoài việc giảm sự phức tạp của ngôn ngữ cốt lõi, chúng cũng đơn giản hóa tình huống nếu chúng ta có nhiều hơn một loại chức năng.Đây là trường hợp trong các hệ thống cơ cấu nơi chúng ta có các chức năng tuyến tính và phi tuyến tính.Ví dụ, trong ngôn ngữ lập trình Rust, có ba đặc điểm chức năng tích hợp khác nhau Fn, FnOnce và FnMut, khác nhau về cách thức của máy thu3 . 2.4 Weak and Strong Dependent Pairs Trong phần trước, chúng tôi đã chỉ ra cách xác định kiểu Π. Đối với kiểu Π, chúng tôi không có lựa chọn nào khác ngoài việc xác định nó là kiểu codata4 , nhưng đối với kiểu Σ, chúng tôi có thể chọn liệu mô hình nó là kiểu dữ liệu hay kiểu codata. Lựa chọn này phân biệt giữa các kiểu Σ yếu và mạnh [Howard 1980]: Các kiểu Σ mạnh được xác định là kiểu codata với hai dự đoán, trong đó dự đoán thứ hai đề cập đến kết quả của dự đoán đầu tiên trong kiểu trả về của nó; ngược lại, các kiểu Σ yếu được xác định là kiểu dữ liệu với một nhà xây dựng ghép đôi yếu tố đầu tiên và thứ hai. Sự khác biệt này rõ ràng hơn nếu trước tiên chúng ta xem xét trường hợp của các cặp không phụ thuộc, cũng có thể được viết là dữ liệu hoặc kiểu codata. Hai đại diện này có thể được lấy từ nhau bằng cách phân hủy chức năng và phân hủy chức năng. Điều này vẫn là trường hợp khi chúng ta tổng quát các cặp không phụ thuộc vào loại Σ. Tương tự như loại π trong Phần 2.3, loại Σ được lập chỉ mục bởi một gia đình loại T. Là một kiểu dữ liệu, nó được định nghĩa bởi một cặp xây dựng lấy kiểu gia đình T , một yếu tố x của loại A và một nhân chứng w làm đối số. Là một loại codata, chúng ta vẫn có hai dự đoán π1 và π2 như trong trường hợp các cặp không phụ thuộc. Nhưng dự đoán thứ hai bây giờ sử dụng tham số tự để đảm bảo rằng một yếu tố của loại T được áp dụng cho selfπ .1 được trả về. Trong thực tế, Agda đã có thể đại diện cho Σ-types theo cả hai cách này. Nhưng có một lời cảnh báo: Agda không được thiết kế ban đầu với các loại codata trong tâm trí, và các loại codata của nó được thực hiện trên các bản ghi phụ thuộc, điều này giới hạn loại codata nào có thể. Ví dụ, thứ tự của những kẻ hủy diệt trong một loại codata là vấn đề cho Agda, vì vậy chúng ta không thể sắp xếp lại chiếu đầu tiên và thứ hai. Trong hệ thống của chúng tôi, những kẻ hủy diệt của loại codata không được sắp xếp và có thể liên quan lẫn nhau, điều này phản ánh chính xác cách thức các định nghĩa được tái diễn lẫn nhau trên mũ. Nhưng tại sao chúng ta nên quan tâm đến hai mã hóa thay thế của kiểu Σ? Lấy ví dụ, Eisenberg et al. [2021] người thảo luận về việc thêm các kiểu hiện hữu vào Haskell. Vì Haskell cả hai là lười biếng và hỗ trợ xóa kiểu, Eisenberg et al. được thúc đẩy đến một thiết kế sử dụng các kiểu hiện hữu mạnh mẽ. Chúng tôi nghĩ rằng bằng cách sử dụng khung dữ liệu và kiểu codata, chúng tôi có thể làm cho những sự khác biệt này rõ ràng hơn. 2.5 Codata Encodings of Natural Numbers Bắt đầu với sự khởi đầu của tính toán lambda, các nhà nghiên cứu đã quan tâm đến các mã hóa chức năng của các loại dữ liệu như boolean, số tự nhiên và danh sách. Ví dụ cổ điển của mã hóa chức năng là các mã hóa của các loại dữ liệu Church, Scott và Parigot (xem Geuvers [2014]; Koopman et al. [2014]). Chức năng từ quan điểm của chúng tôi chỉ là một trường hợp cụ thể của một loại codata, vì vậy chúng tôi quan tâm đến vấn đề chung hơn của mã hóa codata thay vì mã hóa chức năng. Hầu hết các mã hóa codata của các loại dữ liệu có thể được thu được bằng cách refunctionalizing một loại dữ liệu với một quan sát thích hợp. rằng mã hóa nhà thờ có thể được thu được từ refunctionalizing một chương trình với số Peano và một chức năng iter đã được quan sát bởi Ostermann và Jabs [2018]; chúng tôi lặp lại ví dụ này trong Hình 6. Chúng ta có thể quan sát thấy rằng loại codata trong Hình 6b đại diện cho các mã hóa Giáo hội của các số tự nhiên không phải là tái phát. Điều này tương ứng với nguyên lý nổi tiếng rằng các mã hóa Giáo hội có thể được in trong hệ thống tinh khiết F. Nếu chúng ta áp dụng cùng một phương pháp để có được các mã hóa Scott hoặc Parigot của các số tự nhiên, sau đó chúng ta có thể quan sát thấy rằng các loại codata kết quả là tái phát. Điều này tương ứng với nguyên lý nổi tiếng khác rằng các mã hóa này không thể được in trong hệ thống tinh khiết F và yêu cầu các loại tái phát. Geuvers [2001] cho thấy rằng các mã hóa trước đây không thể thể hiện sự induction hoặc loại bỏ phụ thuộc. Một cách để có được các mã hóa chức năng kiểu có thể thể thể hiện sự induction là để thêm một hình thức của tự loại vào hệ thống; loại mã hóa này đã được giới thiệu bởi Fu và Stump [2014]. Trong khi nó là khó để chứng minh một sự tương ứng chính xác, chúng tôi nghĩ rằng ý tưởng thiết yếu của việc mã hóa của Fu và Stump có thể được thể hiện trong hệ thống của chúng tôi trong Hình 7 và Hình 8. Trong Hình 7, chúng ta đã mã hóa induction bằng cách sử dụng một trợ lý codata loại StepFun mà mã hóa bước induction cho một predicate P trên số tự nhiên. induction sau đó được thể hiện như sự quan sát ind trên một số tự nhiên n mà mong đợi trường hợp cơ sở và bước induction của induction như các đối số. đối số n mà chúng ta định nghĩa quan sát xảy ra chính nó trong loại trở lại. Chúng tôi nghĩ rằng đây là bằng chứng thêm rằng các tham số tự giới thiệu vào hệ thống xảy ra tự nhiên khi chúng ta chuyển từ không phụ thuộc vào thiết lập phụ thuộc. 
 
 
 Tác giả : 
 
 
 
 
 Ông David Binder Ingo Skupin Tim Süberkrüb Klaus Ostermann Authors: 
 
 
 
 
 Ông David Binder Nhóm Ingo Lời bài hát: Tim Overkrüb Chủ tịch Klaus Ostermann 
 
 Tài liệu này có sẵn trên archiv dưới giấy phép CC 4.0. Bài báo này là theo giấy phép CC 4.0. available on ar xiv xiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

Why was the 'Hello' afraid to meet 'World'? Because every time they got concatenated, they lost their space!

Concatenation

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Suy nghĩ lại OOP thông qua các loại phụ thuộc và Codata

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

85 Stories To Learn About Travel

189 Stories To Learn About Reading Books

287 Stories To Learn About Blockchain Development

223 Stories To Learn About Science

85 Stories To Learn About Travel

189 Stories To Learn About Reading Books

287 Stories To Learn About Blockchain Development

223 Stories To Learn About Science

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps