12

フローチャート。1000年以上もの間使用されてきたこの古代の古い慣習は、私たちに貧しい学生に何の有用性もなく強制されています（またはそう思います）。命令型の順次実行言語でうまく機能するかもしれませんが、私の最愛の関数型プログラミングはどうですか？

悲しいことに、私は自分のプログラムのフローチャートを作成することを余儀なくされています（それはHaskellで書かれています）。

私はこのようなことは簡単だと思います：

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

これは、データのフェッチ、大文字化、出力の3つのシーケンスステップです。

今回は状況が悪化しています。

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

またはこのように：

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

さて、それはIOでした、あなたは命令型言語のようにそれを扱うことができます。純粋関数はどうですか？

実際の例：

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

最後のフローチャートをどのように作成しますか？

4

4 に答える 4

13

プロセス（したがって状態の変化）を表すフローチャートは、ほとんどステートレスであるFPには適していないと思います。

でも回路図（？）は見せられると思います。

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

インストラクターに相談したほうがいいです。

于 2010-05-03T14:34:15.473 に答える
4

実際、ソフトウェアで使用するフローチャートは約60年前にさかのぼります。（実際、プログラミングは、私たちが知っているように、65年までさかのぼります！）当時、プログラミングは、非常に面倒でエラーが発生しやすい「コーディング」段階の前に、アルゴリズムを計画および開発するためのツールとして非常に重要でした。

最近、私たちのプログラミング言語は、アルゴリズムの意図がコード自体によってより明確に表現される表現力のレベルに達しています。（おそらくVisualBasicほどではありませんが、Haskellでは確かにそうです。）したがって、最近のプログラミングショップではフローチャートを使用していません。

ただし、ビジュアルプログラミング言語は存在し、一部の分野で大きな成功を収めています。これらの環境はフローチャートに関連しています。おそらく、あなたのインストラクターは実際にある程度の比較プログラミング言語の仕事をする準備をしていて、あなた方全員をこれらのアプローチについて考えるように導いています。

最後に、目前の特定の問題について、次のように考えてください。従来のフローチャートは、プログラムを介した制御の流れを主に示していました。これは、当時人々が書いていた種類のコードだからです。ただし、常にある程度のデータフローも示されていました。関数型プログラムの場合、主にデータフローをデモンストレーションします。

ただし、秘訣は、（部分的に適用された）関数のフローをデータとして説明する方法を理解することです。2つの場所で呼び出すことができるサブルーチンの概念をサポートするためにフローチャートが何をしなければならないかを考えてください...これで、「Ⓐで識別される関数がfilter「I」の2番目の引数として流入する」という意味の同様のグラフィカル構造を作成できます。 fmapmⒶを矢印で接続するために、側面に鍵穴が刻まれた小さな弓を想像してみてください。

他に何もない場合は、これをプログラムの代替表現を探索する際の割り当てと考えてください。フローチャートを拡張している場合（一般的な関数を処理する必要はありません）、それを明確にすると、インストラクターは追加のマークを付ける必要があります。

于 2010-05-03T15:32:59.277 に答える
2

フローチャートとFPの手がかりは、機能フローで考え始めることです。ご存知かもしれませんが、FPは、関数を呼び出してジョブを実行する関数に基づいています。誰が誰にどのような情報を使って電話をかけるのかについての良いイメージがない場合でも、スパゲッティコードを作成したり、同じことを実行する関数を大量に作成したりすると、コードの保守が非常に困難になります。

作成する予定の構造図を、発生する順序を説明するフローチャートを使用して作成すると、保守が容易でテストが容易なプログラムになります。

構造図に慣れていない場合、これは、送信値と戻り値を使用して、呼び出し元から受信者への関数呼び出しをモデル化する方法です。これを使用すると、設定ファイルからデータを取得してシステム内の任意の場所で再利用する機能がすでにある場合は、簡単に海を見ることができます。

于 2012-04-05T09:04:04.470 に答える
2

うーん...コードをスーパーコンビネーターベースの表現に手動でコンパイルしてから、そのスーパーコンビネーターアプリケーションのフローチャートのようなグラフを描くことができます。場合によっては、そうすることで、フローの妥当な視覚的表現が得られて便利です。実行フローではなく、データ フローを考えてみてください。

于 2010-05-03T14:49:20.420 に答える