top
recent
FP:素朴な疑問
関連ページ
FP
目次
- 関数と答え...
- HowではなくWhat...
- 再帰は関数プログラミングの専売特許ではない...
関数と答え
関数の答えを変数が保持するのが非関数型言語で、
関数の答えを関数自体が責任(?)もって保持する(つーか保持してるかどうかなんて些事はユーザーから隠蔽される)のが関数型言語、
でしょうか?
- 何時どのように計算、評価されても同じ結果になることが参照透明性なので、関数も変数も値を保持する必要は無い。ということでは?関数が過去の計算結果を保持し、再利用するとプログラムの高速化も可能かもしれませんね。
-- 計算、評価の過程を考えるというのは難しいことのように、私は感じています。ご存知のことかも知れませんが、プログラムが如何動くかという問題もコンピュータサイエンスの方々が研究されています。ある程度、研究は進んでおり、参照透明性があれば何とかなるということが証明されています。研究は、参照透明性の無い実用的な言語でも適用できるようにと進めているようです。その研究は
--- プログラムの「表示的意味論」「操作的意味論」
--- 形式論理学の完全性を使う「Curry-Howard対応」
--- HoareのCPS理論(これは関数型言語ではなく手続き型言語でもいける)
--というものだったと記憶しています。これ以外に、見当違いかもしれませんが関係しそうなネタもあります。
--- ラムダの「α同値性」
--- 項書き換えシステムの「合流性」
----
まだ勉強が足りないので、上記の言葉は目にした程度なんですが、関数型というのはプログラミングパラダイムで、関数型言語はそれを支援/強制する要素をもつ言語ということになると思います。
例のCでも考え方としてのOOはできるという話と同じで、Rubyでも考え方としてのFPはできると思います。
FPな考え方とは何か、まだ自分でもはっきりつかめていませんが、HowでなくWhatでものを考える、ということなんじゃないかと、なんとなく感じています。
# SHIMADA
----
「HowでなくWhatで」という標語は、「どんな種類の」抽象化においても、見かける標語ですよね(^^;。
だから、抽象化(かな)手法の違いを考えるときには、これを持ち出しても情報量がかなり少ないです…。 -戯
保持する必要が無い、というよりは、保持してもしなくてもいい(処理系がarbitraryに決めてもいい)、という感じ?
[[id:1024]] 2002-08-22 12:56:17
HowではなくWhat
Re: 関数と答え
(#1)
どんな種類の抽象化でも出て来るんですか…。しょぼーん。
不勉強なのがバレてしまうなー。
- どっかで書いた「宣言的な」っていう話と同じですし.関数の定義は事実の羅列で関数の計算は等価変換の連鎖.
関数の答えを関数が保持する、というとらえ方はちょっとピンときませんでした。
関数を呼んで答えを変数に束縛するというのも自然な感じがします。→ let ですね。
- どっかでやってた memoize そのものですね?
それより、関数を呼ぶのに返り値が捨てられるということのほうが考え方から外れている気がします。 -- SHIMADA
- 結局副作用をどう考えるかっていう問題に戻ってくる....
----
少なくとも、OOP界隈でも耳タコなくらいに頻繁に使われた言い回しだったかと>[[id:self]]
察するに、構造化が登場したときや、高級言語が登場したときや、アセンブラが登場したときや…にも出たのでは?
要するに、それぞれの方法論は、その方法論が得意とする或る事柄において、[[id:self]]を実現しているのではないでしょうか?
で、今その方法論にLOVEしてる(^^;人は、LOVE(=盲目)してるがゆえに、その事柄の改善こそが偉大に見えて、他の方法論の手柄のほうは忘れる、と。
まあ気分の問題は最終的にどうでもいいんですが、
複数の方法論の手柄が互いの手柄の足を引っ張りあう関係(技術的に)になってしまう場合は、悩ましいですね。
あちら立てればこちら立たずになっちゃうわけですから、勿体無い…
[[id:1030]] 2002-08-23 12:20:18
再帰は関数プログラミングの専売特許ではない
いや、当たり前なことですけどね。
副作用を嫌うことの副作用(^^;により、Loopを嫌って再帰を使うことになる、ということなのでは?>関数プログラミング
-同じ意味を持つモノは2つ(Loopと再帰)はいらないということなのでは?
[[id:935]] 2002-08-14 00:26:58
top
recent
HashedWiki version 3 beta
SHIMADA Keiki