>>478
>前半は余計だと思う。

かもしれない。無視してくれ。

>これは関数指向設計技法の話なんだよね。
>関数型言語を用いてプログラムする前の段階、設計の段階の話だよね。

そう、設計段階の話。要求分析よりも後工程だけど、詳細設計よりも前の(中盤の)設計工程。

>> そのコードが正しく(エラー無しに)処理系で読み込めるか確認しよう。
>これは具体的にはどういうことなんだ。

入力画面や出力帳票に表れる用語と、それら用語の論理的な構造(関連)は、システムをblack-boxとして見た
外部仕様、あるいは機能仕様(の一部)に相当する。この様な外部仕様というのは、開発の現場では、Word/Excel/Visioなどで
作成した文書のレビュー＆手直しを繰り返すことで設計を進めるのが一般的。けれども、その設計課程で生じた
「仕様の誤り/矛盾/曖昧さ/欠落」といった要素は自然語とお絵描き図に埋もれてしまい、明白なミスは指摘できても、

・外部仕様について、少なくとも(構造的な、あるいは構文/文法的(syntax)な)エラーは存在していない

ことまでは証明できない。(意味的(semantic)なエラーについては、ここでは考えない。難しいから.....)
これを解決するため、自分はこれまで yacc(bison) や racc といったパーザジェネレータによる構文検査(syntax cheking)を
試行してきたが、この

・外部仕様の構文検査に、代数的データ型に関する強力な型検査/型推論機能が適用できるのではないか

と考えている。特に、これまでのパーザでは「データ型」という概念では検査不可だったのが、可能になる点に期待している。