>>32
>単に関数指向設計技法の提案でしかない（それも曖昧だが）。

>>8,10で書いたのは、関数合成の自動生成法に関する妄想であって、関数指向設計技法ではないよ。
関数指向設計技法は(前スレ>>989で書いた)以下のように曖昧なもの。

>（２）副関数群への分解手順(アルゴリズム)について、JSP法の考え方に沿って(JSP法を模倣して、あるいは
>　　　JSP法の用語を使って)、指導者が普通のプログラマへ説明する

だから技法(テクニック)でしかない。構造不一致問題に対しては、今まで通り、プログラマの持つ
プログラミング知識を前提にした、経験と勘による手法で対応するしかない。
ただ、それだけであっても「静的関数型言語の持つ(型推論のような)優れた特性があれば、
上流設計工程における品質の向上というソフトウェア工学上の利点は十分に得られる」はずだよね、というのが
前スレで書いた関数指向設計技法の要旨。

で、そんな静的関数型言語の持つ優れた特性は、(Haskellのように実行順序が定まらずモナドに頼らなければ
入出力すらまともに書けない非正格な関数型言語でなくても、)F#やSMLのような正格な言語にも備わっている。
事務系処理で本質的に無限リストが必要になるケースなんてほとんど無いんだから、正格な言語で十分。
しかもF#やSMLなどであれば、明示的な可変宣言をすれば副作用を許容しているのだから、初学者には、
（１）まず手続き型言語で学んだ普通の(副作用だらけの)アルゴリズムで設計し、
（２） 関数型言語の学習を進めていく課程でmap/filter/遅延ストリームのような技法を習得することで
　　　（１）のアルゴリズムを徐々に改善していく
といった指導法を採ることができる。これなら業務用パッケージ/コンポーネントが整備されすれば、
今すぐにでも「関数型言語を普及させる(=従来の手続き型言語を置き換える)」提案を進められる。
(だから、Windowsでは特に、F#は急速に普及していく潜在的可能性があるだろうし、今すぐにでもお勧めしたい)

(長いので続く)