Lưu đồ ngôn ngữ lập trình chức năng

Question

Lưu đồ. Thực hành cổ xưa này đã được sử dụng hơn 1000 năm nay, bị ép buộc khi chúng ta học sinh nghèo, không có bất kỳ sự hữu ích nào (hoặc tôi nghĩ thế). Nó có thể hoạt động tốt với các ngôn ngữ bắt buộc, tuần tự chạy, nhưng những gì về chương trình chức năng yêu quý của tôi?

Đáng buồn thay, tôi buộc phải tạo biểu đồ luồng cho chương trình của tôi (được viết bằng Haskell).

tôi tưởng tượng nó là dễ dàng cho một cái gì đó như thế này:

main :: IO() 
main = do 
    someInput <- getLine 
    let upped = map toUpper someInput 
    putStrLn upped 

Đó là chỉ trong 3 bước trình tự, lấy dữ liệu, uppercasing nó, xuất ra nó.

Những điều trông tồi tệ hơn thời gian này:

main :: IO() 
main = do 
    someInput <- fmap toUpper getLine 
    putStrLn someInput 

Hoặc như thế này:

main :: IO() 
main = interact (map toUpper) 

Được rồi, đó là IO, bạn có thể xử lý đó như một ngôn ngữ bắt buộc. Còn các chức năng thuần túy thì sao?

Một ví dụ thực tế:

onlyMatching :: String -> [FilePath] -> [FilePath] 
onlyMatching ext = filter f 
    where f name = lower ('.' : ext) == (lower . takeExtension $ name) 
     lower = map toLower 

Làm thế nào bạn sẽ Flowchart rằng người cuối cùng?

Answer 1

Tôi không nghĩ sơ đồ, đại diện cho các quy trình (do đó thay đổi trạng thái), phù hợp với FP, phần lớn là không trạng thái.

Nhưng tôi nghĩ bạn có thể hiển thị sơ đồ mạch (?).

 ext 
     _ | ______________________________________________ 
     | |            | 
     | `-> [ '.' : ] -------> [ lower ] --.__   | 
     |          __ [ == ] -----> 
name --> [ takeExtension ] ---> [ lower ] --'   | 
     |__________________________________________________| 
           f 

Bạn nên tham khảo ý kiến ​​người hướng dẫn.

Answer 2

Hm ... Bạn có thể biên dịch mã của mình theo cách thủ công thành biểu diễn dựa trên siêu kết nối và sau đó vẽ biểu đồ giống như sơ đồ của ứng dụng siêu kết nối đó. Trong một số trường hợp, nó thậm chí còn hữu ích để làm như vậy, cung cấp cho một số đại diện trực quan hợp lý của dòng chảy. Chỉ cần nghĩ về luồng dữ liệu thay vì luồng thực hiện.

Answer 3

Thực tế, flowcharts để sử dụng trong ngày phần mềm chỉ sau 60 năm. (Và thực sự, lập trình, như chúng ta biết, ngày trở lại chỉ 65!) Vào thời điểm đó chúng cực kỳ quan trọng như một công cụ để lập kế hoạch và phát triển các thuật toán trước giai đoạn rất tẻ nhạt và dễ bị lỗi "mã hóa".

Những ngày này, ngôn ngữ lập trình của chúng tôi đã đạt đến mức độ biểu đạt, trong đó ý định của thuật toán được biểu hiện rõ ràng hơn bằng chính mã. (Có lẽ không nhiều trong VisualBasic, nhưng chắc chắn trong Haskell.) Do đó, không có cửa hàng lập trình hiện đại nào sử dụng lưu đồ.

Tuy nhiên, visual programming languages tồn tại và có thành công lớn trong một số trường. Những môi trường này liên quan đến flowcharting. Có lẽ người hướng dẫn của bạn thực sự đang chuẩn bị thực hiện một số công việc ngôn ngữ lập trình so sánh, và đang dẫn dắt tất cả các bạn suy nghĩ về những cách tiếp cận này.

Cuối cùng, đối với vấn đề cụ thể của bạn, hãy nghĩ về nó theo cách này: Sơ đồ truyền thống chủ yếu thể hiện luồng kiểm soát thông qua một chương trình, vì đó là loại mã người viết vào thời điểm đó. Tuy nhiên, luôn có một số dòng dữ liệu được minh họa. Đối với một chương trình chức năng, bạn sẽ chủ yếu trình diễn luồng dữ liệu.

Bí quyết, mặc dù, đang tìm hiểu cách minh họa luồng của (một phần được áp dụng) chức năng dưới dạng dữ liệu. Hãy nghĩ về những gì flowcharting phải làm để hỗ trợ khái niệm về một chương trình con có thể được gọi ở hai nơi ... Bây giờ có lẽ bạn có thể tạo ra cấu trúc đồ họa tương tự để có nghĩa là "hàm được xác định bởi Ⓐ dòng như đối số thứ hai của filter" I đang tưởng tượng một cây cung nhỏ có nhãn fmap với một lỗ cắt chính ở bên cạnh để được kết nối với mũi tên.

Nếu không có gì khác, hãy coi đây là bài tập để khám phá các đại diện thay thế cho chương trình của bạn - và nếu bạn mở rộng sơ đồ (không bao giờ phải đối phó với các chức năng chung), và làm rõ điều đó, người hướng dẫn của bạn sẽ cho bạn dấu phụ!

Answer 4

Đầu mối với biểu đồ lưu lượng và FP là bạn bắt đầu suy nghĩ trong Luồng chức năng. Như bạn có thể biết bây giờ FP xây dựng các chức năng gọi hàm để hoàn thành công việc. Nếu bạn không có hình ảnh tốt về ai sẽ gọi ai với thông tin nào bạn vẫn sẽ tạo mã spaghetti hoặc tạo nhiều chức năng làm cùng một mã khiến mã của bạn rất khó duy trì

Tạo Sơ đồ có cấu trúc của những gì bạn dự định xây dựng với biểu đồ luồng mô tả thứ gì cần phải xảy ra, bạn sẽ kết thúc bằng một chương trình có thể duy trì và dễ kiểm tra hơn.

Đối với những người không quen thuộc với Biểu đồ cấu trúc, đây là cách để mô hình cuộc gọi chức năng từ người gọi đến người nhận bằng giá trị gửi và trả lại. Với nó bạn có thể dễ dàng biển nếu bạn đã có một chức năng lấy dữ liệu từ một tập tin cấu hình tức là và tái sử dụng nó bất cứ nơi nào trong hệ thống của bạn