Yêu cầu tham khảo: Lý thuyết danh mục vì nó áp dụng cho các hệ thống loại


13

Tôi tiếp tục nghe về cách người ta phải học lý thuyết thể loại để thực sự hiểu lý thuyết ngôn ngữ lập trình. Cho đến nay, tôi đã học được rất nhiều PL mà không bao giờ bước chân vào vương quốc của các thể loại. Tuy nhiên, tôi cho rằng đã đến lúc phải thực hiện bước nhảy vọt để xem những gì tôi đã bỏ lỡ.

Thật không may, không có nguồn nào tôi có thể tìm thấy dường như thực hiện bất kỳ kết nối nào để gõ hệ thống hoặc lập trình. Họ nói rằng đó là một giới thiệu về lý thuyết thể loại cho các nhà khoa học máy tính, nhưng sau đó chuyển sang những thứ vô nghĩa trừu tượng chung (tôi nói điều này một cách đáng yêu) mà không đưa ra bất kỳ ví dụ hay ứng dụng thực tế nào.

Tôi đoán câu hỏi của tôi thực sự là hai lần:

  1. Là lý thuyết thể loại cần thiết để hiểu "khái niệm sâu sắc" trong PL?
  2. Nguồn nào giải thích lý thuyết danh mục theo quan điểm của các ứng dụng thực tế để gõ hệ thống và lập trình?

Cho đến nay, điều xa nhất mà tôi nhận được là về một quan niệm mơ hồ về functor (dường như không liên quan đến functor trong ML, theo như tôi có thể nói). Tôi sợ sự trừu tượng mà tôi cần phải giữ trong đầu để hiểu các đơn nguyên từ quan điểm lý thuyết thể loại.


2
@Raphael Một ý kiến ​​tồi là đặt một câu hỏi bao gồm hai câu hỏi khác nhau chỉ liên quan đến nhau một cách mơ hồ. Nhưng câu hỏi 1. không chủ quan. Nó là một yêu cầu để làm rõ và giải thích. Tôi đoán câu hỏi 2. có nghĩa là anh ấy hài lòng với một tham chiếu đến một nơi mà nó được giải thích thay vì một lời giải thích thực tế quá.
Thomas Klimpel

2
Trong tương lai, tốt hơn là chỉ hỏi một câu hỏi cho mỗi bài đăng. Bạn có thể đặt câu hỏi 1, sau đó tùy thuộc vào câu trả lời bạn nhận được, quyết định có nên hỏi riêng câu hỏi 2 không. Điều đó thường làm cho mọi thứ diễn ra suôn sẻ hơn.
DW

1
@Raphael Làm thế nào là một câu hỏi chủ quan? Có thể khó đánh giá - đó có phải là ý bạn không? Và nó có thể có câu trả lời như thế nào. Nó phụ thuộc vào bạn là người như thế nào. Ý - đó có phải là ý bạn không? Nó vẫn có thể chỉ ra rằng nó thực sự cần thiết hoặc chắc chắn không thiết yếu, phải không? (Và mọi người dường như đồng ý rằng điều đó không cần thiết.)
k.stm

1
@ k.stm Hình dạng chung của câu hỏi làm tôi lo lắng. Nếu ai đó muốn hỏi, "Đại số có cần thiết để hiểu các khái niệm sâu sắc của ngôn ngữ chính thức không?", Tôi biết thực tế là những người khác nhau sẽ đưa ra câu trả lời khác nhau - dựa trên sở thích và sở thích của họ. Tôi không hy vọng nó sẽ khác ở đây.
Raphael

1
@Raphael Được rồi, tôi hiểu rồi. Nhưng tôi nghĩ rằng mọi người đang đưa ra câu trả lời chủ quan cho một câu hỏi khách quan. (Cảm giác như mọi người đang nói, ồ, tôi uống năm cốc một ngày và tôi cảm thấy rất tuyệt!
Nghi

Câu trả lời:


15

Lý thuyết danh mục không cần thiết để hiểu ngôn ngữ lập trình, thậm chí không cần thiết phải nghiên cứu nâng cao về ngôn ngữ lập trình. Hầu hết các ngôn ngữ lập trình mọi người không biết (nhiều) lý thuyết thể loại.

Các phương pháp lý thuyết danh mục đã hữu ích chủ yếu trong một phần nhỏ của nghiên cứu ngôn ngữ lập trình, cụ thể là trong phân tích lập trình chức năng, đặc biệt, vì khám phá tuyệt vời của Moggi rằng một số hiệu ứng tính toán có cấu trúc đơn âm. Vào những năm 1990, sau bước đột phá của Moggi, rất nhiều nghiên cứu đã được thực hiện để mở rộng các phương pháp phân loại sang các dạng ngôn ngữ lập trình khác. Tuy nhiên, theo hiểu biết tốt nhất của tôi, các phương pháp phân loại chưa tìm thấy tất cả những gì hữu ích cho OO, tính toán đồng thời, song song và phân tán, tính toán theo thời gian hoặc trình biên dịch. Vì lý do này, mọi người chủ yếu đã từ bỏ việc mở rộng các phương pháp phân loại.

Các cách tiếp cận phân loại để lập trình đánh máy hoạt động tốt trong các hàm thuần túy. Thật vậy, một số hệ thống gõ đơn giản là thể loại. Điều này được mô tả trong ví dụ

Hiện tại có rất nhiều công việc về các loại cho các quy trình đồng thời (ví dụ như các loại phiên) và không có loại nào có tính chất phân loại kể từ tháng 9 năm 2016.

Điều đó nói rằng, người ta không bao giờ có thể biết quá nhiều toán học, và biết lý thuyết thể loại là hữu ích. Vì vậy, đó là một câu hỏi về chi phí / lợi ích. Nếu bạn thích môn toán, nếu có thể bạn có một chút nền tảng về đại số (ví dụ: nhóm miễn phí trên một tập hợp, vòng miễn phí, v.v.) thì việc học lý thuyết thể loại sẽ dễ dàng và nếu bạn có kế hoạch thực hiện công việc (lấy cảm hứng từ) lập trình chức năng, biết danh mục sẽ hữu ích.

Cuối cùng, lý thuyết phạm trù là toán học đẹp và đáng để nghiên cứu đơn giản vì nó rất gọn gàng.


Xem đóng góp của Uday Reddy trong cuộc thảo luận này để có cái nhìn khác.


"Tuy nhiên, theo hiểu biết tốt nhất của tôi, các phương pháp phân loại chưa được tìm thấy hoàn toàn hữu ích cho ..." Đó chính xác là vấn đề của tôi. Ngữ nghĩa hoạt động có thể mô tả chính xác tất cả các khái niệm này, vì vậy tôi không cảm thấy như mình đang bỏ lỡ. Tôi yêu toán học, nhưng nền tảng của tôi về đại số trừu tượng thật đáng buồn. Tôi chỉ hiểu những điều cơ bản của các cấu trúc đại số phổ biến. Điều này đã làm cho lý thuyết thể loại nắm bắt đặc biệt cồng kềnh.
vườn

2
@gardenhead Sau đó, có lẽ CT không hữu ích cho bạn. Nếu bạn muốn đọc nhiều bài viết trong không gian "Lập trình chức năng", bao gồm cả làm việc với các loại, thì rất nhiều trong số chúng sẽ sử dụng ngôn ngữ của CT.
Martin Berger

cái này một bản sao?
Raphael

2
Ngoài ra, tôi cũng đề xuất sách cs.unibo.it/~asperti/PAPERS/book.pdf "Danh mục, loại và cấu trúc", có vẻ như không còn xuất bản, nhưng đó là một liên kết đến pdf từ một trong những Trang chủ của tác giả, vì vậy tôi đoán nó hợp pháp.
John Forkosh

6

Học lý thuyết phạm trù là một khoản đầu tư thời gian rất lớn, và câu hỏi liệu nó có giá trị hay không là rất hợp lệ. Tôi vẫn còn vật lộn với điều này nữa , và tôi đã biết tại sao tôi nên học nó. Tôi đã viết:

Tôi thích ngôn ngữ lắp ráp khi tôi bắt đầu lập trình, và lý thuyết tập hợp cảm thấy giống với ngôn ngữ lắp ráp. Lý thuyết phạm trù là một thay thế để vượt qua tất cả các định kiến ​​khắc về logic và lý thuyết mô hình được nhúng vào lý thuyết tập hợp ZFC chính thống.

Ý tưởng ở đây là sử dụng các danh mục thay vì tập hợp hoặc "bit không xác định" làm ngữ nghĩa có thể cho một lý thuyết loại hoặc ngôn ngữ lập trình nhất định. Tại sao người ta muốn làm điều này? Hãy xem xét tính hai mặt giữa một hành động và một quan sát. Các quan sát khác nhau (hoặc ít nhất là theo thứ tự thời gian của chúng) không can thiệp lẫn nhau (bên ngoài cơ học lượng tử), nhưng điều này không nhất thiết đúng với các hành động khác nhau. Những định kiến ​​khắc sâu về logic được nhúng trong lý thuyết tập hợp khiến cho việc mô hình hóa các hành động trở nên khó khăn, so với các quan sát mô hình hóa.


Tôi không tin rằng thực sự có một sự tương ứng hoàn hảo giữa lý thuyết thể loại và lý thuyết loại như được tuyên bố ở đây :

Với tính đối ngẫu cú pháp - ngữ nghĩa, người ta có thể xem lý thuyết kiểu như một ngôn ngữ cú pháp chính thức hoặc phép tính cho lý thuyết phạm trù, và ngược lại, người ta có thể nghĩ về lý thuyết phạm trù như là cung cấp ngữ nghĩa cho lý thuyết loại.

Đúng là lý thuyết thể loại có thể cung cấp ngữ nghĩa cho lý thuyết loại (có thể thực sự hữu ích), nhưng tôi nghi ngờ rằng lý thuyết loại thực sự cung cấp một ngôn ngữ cú pháp chính thức đủ mạnh để diễn đạt tất cả các tính toán được thực hiện trong lý thuyết thể loại.


Trong thực tế, tính hữu ích của lý thuyết thể loại có thể phát sinh bằng cách đề xuất các câu hỏi và tương tự hữu ích. Nhưng lý thuyết thể loại cũng có thể đề xuất các hoạt động và câu hỏi mà cuối cùng hóa ra chỉ là một sự phân tâm (lãng phí thời gian) từ các vấn đề thực sự quan trọng. Và bạn chắc chắn có thể học logic và loại lý thuyết mà không cần quan tâm đến lý thuyết thể loại.


Cảm ơn những suy nghĩ của bạn. Lý do của bạn để học lý thuyết thể loại dường như khác với tôi; sở thích của bạn xuất phát từ quan điểm toán học thuần túy, trong khi tôi muốn mở rộng hiểu biết về các loại. Tuy nhiên, thật vui khi biết rằng những người khác bao vây bản thân tôi thấy khó tiếp cận và áp dụng
vườn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.