LLにおける関数型プログラミング
>>314
>関数型言語でなければならないという観点は間違ってる気がする
ああ、これについては同感だね
現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、
現行LLであるPerl/Python/Rubyを置き換えるには無理があると思う
ただし、関数型言語にも良い特性がある訳で、実際に(LLを含む)多くの言語に影響を与えている
だから自分は「LLにおける関数型プログラミング」に注目している
> 現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、
その難というのを、もっと明確に言ってほしい。
たとえば、＊＊というプログラムをする上で必要な
文字列に関する＄＄という操作が、
どの関数型言語でもできない、あるいはやりにくい。
など
パターンとハッシュに関しても同様に。
・関数型プログラミング HOWTO ― Python 2.7ja1 documentation
http://www.python.jp/doc/nightly/howto/functional.html
・魅力的なPython: Pythonでの関数プログラミング: 第1回 - IBM dw
http://www.ibm.com/developerworks/jp/linux/library/l-prog/
・Pythonの技法：関数型言語スタイル「関数の部分適用」 - ZDNet Japan
http://builder.japan.zdnet.com/script/20364411/
・Pythonの"関数型"の機能の起源 - The History of Python.jp
http://python-history-jp.blogspot.jp/2009/05/python.html
def add(a, b)
return a + b
end
def curry(f, a)
return lambda { |b| method(f).call(a, b) }
end
add1 = curry(:add, 1)
p add1.call(2)
Rubyは関数オブジェクトを扱えるので、
置き換えるも何も、既にRubyは関数型言語
当然純粋関数型言語ではないし、関数型言語らしく書かない事もできるけど、
関数型言語としての特性を備えている事に変わりはない
そもそもどの言語でも最近関数オブジェクトの取り入れが盛んで、
関数型言語かどうかという分類が既に成り立たなくなってる
C++11ですらカリー化できる時代、
可能なのはせいぜい純粋関数型言語か否かという区別程度だな
http://ideone.com/H82Pn
それのどこがカリー化だアホめ
それはカリー化ではなく、部分適用です。
はいはいわろ
y (b, c) という2引数の関数を戻り値として返す1引数の関数 g (a) のことだ。
関数 f から関数 g を作ることをカリー化という。
では >>7 の中でカリー化された関数とはどれか、明確に示してみよ。
1.9では>>14なんてのもあるみたいだが
def add(a, b)
return a + b
end
def curry(f)
return lambda { |a| lambda { |b| method(f).call(a, b) } }
end
add1 = curry(:add).call(1)
p add1.call(10)
g :: a -> (b -> (c -> d)) を作るのがカリー化
２引数の場合しか動かんようなクソコードなら貼らなくて良いよ
違う
f :: (a, b, c) -> d から
g :: a -> ((b, c) -> d) を作るのがカリー化だ。
-- Wikipedia : カリー化（http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96）
> 複数の引数をとる関数を、引数が「もとの関数の最初の引数」で戻り値が「もとの関数の残りの引数を取り結果を返す関数」であるような関数にすること。
カリー化された関数の戻り値は「もとの関数の残りの引数を取り結果を返す関数」だ。
(b, c) を勝手に b -> c -> と形を変えることまではカリー化には含まれない。
ごめんねーwikipediaは英語見てたわーww
http://en.wikipedia.org/wiki/Currying
> In mathematics and computer science, currying is the technique of transforming a function
> that takes multiple arguments (or an n-tuple of arguments) in such a way that
> it can be called as a chain of functions each with a single argument (partial application).
Ruby でカリー化が本当にできるのかどうかは知らない。
少なくとも、確実に >>7 はカリー化ではないと指摘しているだけだ。
>>16 もなんか怪しい気がする。
カリー化された関数とはどれのことか？
ただ、２引数にしか使えない
1.9ではまんまcurryメソッドが用意されてるので変な事する必要ない
http://www.ruby-doc.org/core-1.9.3/Proc.html#method-i-curry
自前で定義するとこんな感じか
def curry(f):
n = f.__code__.co_argcount
def _(args=[]):
return f(*args) if n == len(args) else lambda x: _(args + [x])
return f if n == 0 else _()
@curry
def foo(a,b,c):
return a + b + c
print(foo(1)(2)(3))
>その難というのを、もっと明確に言ってほしい。
現行のLLにはこれらデータを「簡潔に表現」できる専用の記法/構文がある
以下はRubyの例(これらはPerl(awk?)から影響を受けた(=パクッた)と思われる)
【文字列】 文字列リテラルには「式展開」や「ヒアドキュメント」がある
たとえば "my name is #{$ruby}" は、format "my name is %s", $ruby よりも
簡潔に書ける
【パターン】 「正規表現リテラル」がある。たとえば /^Ruby is OOPL/ は、
Regexp.new "^Ruby is OOPL" よりも簡潔だ
【ハッシュ】 「ハッシュ式」とハッシュ操作のための構文がある
たとえば {a: 1, b: 2} は Hash.new [:a, 1, :b, 2] よりも簡潔だし、
obj[:a] は obj.fetch :a よりも簡潔に書ける
これらの記法/構文はRuby全体からすればほんの一部であり、
LLの主用途(主戦場)である日常的なテキスト処理に特化した様々な工夫が施されている
これらの多くは関数型言語ではライブラリ関数として提供され、
同等な処理は書けてもLLの専用記法/構文と比較すれば冗長である(=めんどくさい)と考える
この暗号みたいなの何？
× 現行のLL
○ Ruby
Ruby 1.9で導入された新しいハッシュ式の記法
以前の記法 {:a => 1, :b => 2} と同じ
UNIXプログラミング環境に住み慣れた人なら、
sh や awk でなじみがあるから好意的に受け止める人は多いのではないかと思う
少なくともWeb開発の世界では、Perlの記法を引き継いだPHP(と一部でRoR)が主流だし...
まあWindowsプログラマからすれば、これらの記法に違和感があるというのは認めるw
元のLL云々ってRuby＆関数型マニアのコイツがLLスレで暴れたいだけの口実だったんだしぃ〜
なんかLLの話するのかと思って釣られてくる被害者が出そうだわぁ〜
まーた関数型言語用のお題ってのを早速コテみたいなのをつけ出したコイツが出してくるんだろぉ〜
都合の良いルールで縛ってさぁ〜、結論ありきの議論は面白いですかぁ〜
>Rubyの関数型プログラミングスレで良かったんじゃねぇ〜？
んー自分はそれでも良かったけど、せっかく>>1がスレを立ててくれたんだから、
Rubyに限定せず、あらゆるLLで関数型プログラミングを語る場になれば....と思う
特に(>>6にあるように)Pythonは関数型プログラミングに関する情報が豊富みたいだから、
Python&関数型マニアの参加は大いに歓迎したいな
camlp4使って構文拡張すれば足りるな
＞Perlの記法を引き継いだPHP
＞Perlの記法を引き継いだPHP
それ変数につく$だけだろｗｗｗｗｗｗｗ
Perlの汚い部分を引き継いだのがPHP
綺麗な部分だけ選んで引き継いだのがRuby
Rubyでは$変数をあまり使わない
perと同じように $_ 使える部分もあるんだけど、基本的には使えない場所のが多い 使えてもいい気がするんだけどな
実際にはActiveRecord/Rails系列の「キーワード風」メソッド引数の mes(sym1: val1, sym2: val2) のときに*しか*使用されない
これ以外の場面で使うのはなにもわかってないただのバカで早晩自爆するので放置でOK
シンボルが
:symbol
こうだから
xx: 4
だといったん、タイプがとまるんだよね
かといって
:xx => 4
だとタイプ数があるし
2.0に期待するしかない
では、逆に関数型言語にはあって、Ruby などの LL には無い機能や仕組みで、
是非 LL にも取り入れてほしいと思ってるものは何？
こちらも詳細にお願いします。
それって人のコード読むときに苦労するよな。そういう用途は対象外なのかもしれないが。
大量の手段あるけど
それはC++みたいにソース見ただけじゃ何やってるかわからない構文は無いんだよ
手段とはいっても
オブジェクト.メソッド で呼び出す形だから
メソッドの動作さえ覚えれば良いだけ
こういうところの考えからPythonとかのリスト内包表記は入れないんだと思う
DSＬに関しては「読みにくくて書きづらくて覚えにくい」で意見の一致をみている
一時期ライブラリがなんでもかんでもDSLっぽい記述になったりもしたが、これからはそんなことは無いだろう
まず各LLにおける関数型プログラミングの適性度には大きな差異があること、
およびLLプログラミングではRubyしか深い経験/知識が(自分には)無いという理由から、
以降で述べる要望は「Rubyだけを対象」にしていることを断っておきます
最初の要望は、理想論であるけど「型推論を前提とした静的型付け」です
LLの主用途は(>>28で述べたように)日常的なテキスト処理であるけれど、
RailsやmRubyなどの登場によって「Rubyで製品を開発する」ケースが増えつつあります
この場合、生産性(効率的な開発)も大切ですが、長期間に渡って運用/開発が継続するという
性格から、品質(バグ発生率や保守性)が最も重要であると考えます
この高品質コード設計においては、生産性(簡潔さ)と高品質(安全性)を兼ね備えた
「型推論を前提とした静的型付け」がRubyに求められることになるでしょう
ただし、サブセットのRuby言語仕様であれば型推論の実験的実装について
いくつかの報告が存在しますが、完全なRuby言語仕様についてはかなり遠い目標でしょう
そこで、これに代わる現実論(=妥協案)として「省略可能な動的型検査構文」を要望したい
これは単純に def hoge(num : Integer, str : String) : MyClass といった構文でもいいし、
typexpr Integer * String -> MyClass のような明示的型式宣言でもいいし、
あるいはPythonのデコレータ記法を応用した型検査手法をパクってもいいと思います
なお、当たり前ですがこの要望は組み込み/標準添付ライブラリに関しても適用されるべきです
この要望は、ドキュメンテーションの改善にも役立てることができます
現在のRubyコミュニティでは、コメントとして記述された型情報を含む解説を抽出するという
JavaDocスタイルの文書化が主流です(たとえば「引数 num は整数、str は文字列 ......」)
ここで、もしも動的型検査構文が導入され、かつ型情報を外部へ出力できるようになれば、
そこからメソッドの型に関する解説を文書の一部として自動生成できるようになるはずです
また「コードとコメントの乖離」というJavaDocスタイル固有の問題(の一部)も解消されます
(続きは、また明日)
二番目の要望は、「可変(mutable)な操作と不変(immutable)な操作の明確化」です
具体的には、Rubyにはオブジェクトの状態を破壊的に更新するメソッドであれば、
そのメソッド名の末尾に !(感嘆符) を付けようという弱いルールが昔から存在していました
(この末尾感嘆符ルールは、Lisp文化に由来すると思われます)
けれどもこのルールは一般にはほとんど普及していませんし、
残念なことに組み込みクラスですらルールが守られていないケースがあります
たとえば、Hashクラスには二つのハッシュを(破壊的に)結合する可変操作merge!と
破壊せずに結合するmergeがある一方で、merge!と同じ可変操作updateが存在します
これはRuby 1.8 -> 1.9 の時点でupdateを廃止するか、あるいはdeprecate(非推奨)を
判断して、リファレンスへ反映させるべきでした
組み込み/標準のクラスですら平気で逸脱しているのだから、ユーザが遵守する訳がありません
関数型プログラミング作法の基本は
「(破壊的代入を含む)副作用を避けた参照透明性のあるプログラミング」
であり、Rubyにおいては
「副作用を極力避けたり、参照透明性のある部分とない部分を意識的に使い分ける、
あるいは副作用のあるコードを隠蔽する」
ことが、高品質コード設計技法では重要になります -- (LLバトルスレ25のレス#255も参照)
一般に普及している手続き型プログラミングでは破壊的操作が基本ですから、
「可変な操作と不変な操作の明確化」への関心はさほど強くなかったことが
現状の背景にあると思いますが、関数型プログラミングによる高品質コード設計では
こんな些細なこだわりも大切になるでしょう
(終わり)
・Functional programming with Ruby
http://www.slideshare.net/tokland/functional-programming-with-ruby-9975242
http://code.google.com/p/tokland/wiki/RubyFunctionalProgramming
・Thinking Functionally In Ruby – A Great Presentation by Tom Stuart
http://www.rubyinside.com/functional-programming-in-ruby-2713.html
・Functional Programming Techniques With Ruby: Part I & Part II
http://rubysource.com/tag/functional-programming/
・Adventures in Functional Programming With Ruby
http://www.naildrivin5.com/blog/2012/07/17/adventures-in-functional-programming-with-ruby.html
but Ruby is arguably better suited to a functional programming style.
Lambdas in Python are generally very short, because lambdas in Python are
restricted to expressions and cannot contain statements.
Ruby's lambda support is far more flexible,
allowing for lambda expressions of arbitrary length.
In a similar vein, Python 2.x's closure support is
more limited than Ruby's thanks to its limited support for lexical scope.
Python 3 introduces the nonlocal keyword which addresses this limitation
by allowing assignment to variables in outer non-global scopes.
On the other hand, as of version 1.8, which is still used widely,
Ruby does not support tail-call optimization for recursive functions,
whereas Python uses a decorator to implement tail-call optimization.
Ruby 1.9 ― the current stable release ― can currently be compiled to
support tail-call optimization.
"Functional Programming - Python vs Ruby"
http://www.wikivs.com/wiki/Python_vs_Ruby#Functional_Programming
> 可変(mutable)な操作と不変(immutable)な操作の明確化
破壊的な操作を内部に一カ所でも含む関数は破壊的になるから、
まともに明確化して分けようとすると、結局 Haskell の IO モナドみたいになりそう。
X: なんで日本はRubyオタクばっかなの？
O: なんで世界はRubyオタクばっかなの？
>破壊的な操作を内部に一カ所でも含む関数は破壊的になる
これは事実であり、特に純粋関数型言語であるHaskellプログラミングでは絶対的な真理でしょう
ただし、別の切り口による２つの考え方もありえると思います
最初の切り口は「純粋関数型 vs. 不純関数型」です
たとえば関数型言語のML族(F#/OCaml/SML)では、不変(immutable)データを操作する
透過的なプログラミングが基本の作法ですが、「例外」として明示的な参照型宣言や
逐次演算子(SMLの場合は ;(セミコロン))を用いた手続き型プログラミングも可能です
言い換えると、純粋関数型言語パラダイムではあらゆる破壊的操作を拒絶するのに対し、
不純関数型言語パラダイムでは例外を受け入れる寛容な思想です
そして、たとえ不純関数型言語パラダイムであっても、(手続き型言語パラダイムと比較すれば)
コード品質に関する明らかな恩恵を享受できることも事実です
Rubyによる関数型プログラミングもまた「不純関数型パラダイム」になります
もう一つの切り口は「ソフトウェアアーキテクチャレベルでの分離」です
たとえばRailsフレームワークは「MVCアーキテクチャ」をもとに設計されていますが、
ModelはRDB操作が、Controlerはセッション管理があるので破壊的操作は避けられないでしょう
でもViewに関してはRDBから取り出した値からHTMLオブジェクトへの「写像」という
純粋な関数として定義できると確信しています
つまり、(クラス/モジュールよりも粒度の高い)コンポーネント/サブシステムという単位で
破壊的操作コードと非破壊コードを分離することが、現場の開発では可能であると考えています
またMVCアーキテクチャはシステムを水平方向に分割しますが、
垂直方向にシステムを分割する「階層化アーキテクチャ」という発想もあります
つまり、I/O処理を含む下位層のコンポーネントは破壊的操作で設計し、
上位層を非破壊操作で設計することになります
もちろん水平分割と垂直分割を組み合わせることも可能でしょう
こういった(コード設計よりも上流の)アーキテクチャ設計も高品質ソフトウェア開発では重要です
例えば Ruby なら、破壊的操作には関数名に ! をつけましょうという、
ハンガリアンと同レベルの命名規則が提案されもしたが、
しっかりと守る人は少なかった。
一方 OCaml などにおいては、参照透過性を保つことを基本としながら、
その中に（明確にマークすることにより）破壊的操作を混ぜることに成功している。
こちらも、破壊的操作はできるが、できるだけ参照透過性を守ろうというのは、
いわば約束であって、そうしなければコンパイルが通らないという話ではないから、
そういう意味では Ruby の命名規則による約束と強制力という点で何ら変わらない。
どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
LL というカテゴリ名が示すように簡単に軽く書けることを信条としてきた言語では、
約束程度の縛りでは「可変(mutable)な操作と不変(immutable)な操作の明確化」
にはなかなか至れないと思う。
自分はそのつもりで守っても、使ってるライブラリでそれを壊してたら、
逆にデバッグ時にある意味不要な柔軟な思考が要求され、ハマる可能性もある。
せめて、内部で一カ所でも破壊的操作が行われていたら、
関数名の末尾に ! を付ける事を構文化して、ルールを守らなければ
インタプリタやコンパイラから警告ではなくエラーを出すようにしないと
明確化には遠いと思う。
deleteとか
delete_if に!ついてねーもの
同感ですね、特に次の一文が....
>どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
>あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
新しいパラダイムの普及や文化の移行には、長い時間が必要です
オブジェクト指向にしても、Smalltalk-80の日本上陸から現在の繁栄の時代まで20数年を要しました
関数型言語からLLの戦場に対応すべく異常進化した新種が誕生するのか(>>28)、
あるいはLL文化が関数型パラダイムへと移行するのか(>>49,54)、未来は予測できませんが
長い目で見守りつつ自身の技(わざ)を磨いていかなければならないと思います
Rubyに関しては、「簡単に軽く書ける」どころか「楽しいプログラミング」を信条としている訳で、
そのRuby固有のユニークな文化は今後も生き続けるでしょうし、自身もそれを望んでいます
Rubyで高品質設計が求められつつあるといっても、その主戦場の重要性に変わりはないのですから....
(>>49,54で言ってる事と矛盾しているような気がしないでもないけど、たぶん気のせいでしょうw)
だから関数型パラダイムへの移行期間では、
・関数型プログラミング技法を用いてRubyで「楽しく」プロトタイプを開発し、それをML族へ移植
・高品質な部品(コンポーネント)をML族で開発し、それらをRubyで糊付
といったアプローチもありかもしれません
また、現実のRubyプロジェクトでは、以下の施策を適用しています
・[>>49] すべてのメソッド定義の出入り口に専用の動的型検査メソッド呼び出しを入れる
・[>>54] 生の組み込みクラスを包む破壊/非破壊操作を分離した独自クラス
例えばどのような命名規則でしょうか。
このスレはあくまでLLにおける関数型プログラミングの話なので、
関数型プログラミングに関わりそうな部分だけで結構ですので、
いくつか例を挙げていただけないでしょうか。
Rubyしか知らないのに他のLLを巻き込むなよ
スレの趣旨を認めたくないのなら、ここに来ないでほしいのだが。
関数型モドキのニセモノに過ぎないから
関数型プログラミングで得られるメリットはLLと然程変わらないね
だからMLユーザがしょぼいライブラリしか無いML処理系じゃなく
LLで関数型プログラミングやりたい気持ちは分かるよ、うん
楽々「できる」のと、苦労すれば「できないこともない」との間にも大きな隔たりがある
>MLは悪くない言語なんだけど、関数型言語としては二流っていうか
>関数型モドキのニセモノに過ぎないから
小学生の書いた読書感想文？
関数型言語としては二流である根拠をはっきり述べてくれ。
そして、関数型プログラミングで得られるメリットとは何かも述べてくれ。
もし気力が残っているのなら、そのメリットがMLでは得られないのは、
MLの何に原因があるのかも述べてくれると、大変よろしい。
LLスレで暴れてたRuby&関数型マニアのキモイ奴だけだろ
プライドがズタズタになっていない>>28は本当に凄い
Pythonはシェア1位を取ってるよ
関数型プログラミングがやりやすい言語を選ぶなんてこともない
C++でもラムダが使える時代だから関数型プログラミング最高！という短絡思考はやめた方がいい
むしろ、Ruby以外は常識的判断により関数型からは慎重に距離を置いてる
結果としてRubyだけが関数型言語と同様の馬鹿げた真似をしてドヤ顔してるって感じ
本当にLisper得意の見下しって時代から何も進歩してない
まあML＆Rubyの人は好きにやれば良いんじゃないかな
例えばどういうRubyコードのこと言ってる？
Rubyにおける関数型プログラミングなの？
def func n , aa , bb
Enumerator.new do | e |
a = aa.cycle
b = bb.cycle
[*[b]*n.-(1),a].cycle { |r|
e << r.next
}
end
end
これって
数値ではないわけで
チャーチ数のみでゲームをつくっても人間には何がおもしろいのかわからないものができあがりますよね
だからチャーチ数をどこかで人間がみて理解できる数値に変換していいんだとおもいますけど
それって途中までチャーチ数で演算した意味は？ってきかれるとまだ僕には答えられません
つまり最終成果物は十進数の数値なんですが
途中演算をλ計算でやる利点はなんですか？
なにがあるんですか？
なんかそんな気がします
用途があるとすればそこでしょうか
これ凄いですね
演算速度がどれだけ桁増えても一定である気がします
それであってますか？
レスまだ？
おそくない？
ラムダ計算はこんなに高速だってのにおまえ等は、、
cpu内部にラムダ計算入れるべき
自分で理解した
ラムダ計算は最速の演算方法だ
nilの扱いと名前空間
けどｊａｖａにくらべたら全然余裕
・JavaScript 第6版 - O'Reilly Japan
http://www.oreilly.co.jp/books/9784873115733/
-- 第5版からの改訂として、節「8.8 関数型プログラミング」が追加された
・Javascriptで学ぶ Functional Programming
http://www.slideshare.net/todorokit/javascript-functional-programming-10170360
・JavaScriptで始める関数型プログラミング 1-1 - サイバーエージェント公式クリエイターズブログ
http://ameblo.jp/ca-1pixel/entry-11144877522.html
・エレガントな JavaScript を作成するための関数型プログラミングの使用 - IBM dw
http://www.ibm.com/developerworks/jp/web/library/wa-javascript.html
・A Modern Introduction to Programming with JavaScript and jQuery - Open Book Project
http://www.openbookproject.net/books/mi2pwjs/index.html
・JavaScript as a Functional Language
http://www.ajaxprojects.com/ajax/tutorialdetails.php?itemid=557
Rubyによる関数型プログラミング -- Functional programming with Ruby
・http://www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html
・http://www.h6.dion.ne.jp/~machan/misc/FPwithRuby.epub
>>80
>>79のいう「関数型言語と同様の馬鹿げた真似をしてドヤ顔してる」とは、
たとえばこんな記事(および、記事に含まれるコード群)を指しているのだと思われ.....
curry = lambda x : lambda y : x + y
curry (1)(2)
add = lambda x, y, z : x + y + z
curry1 = lambda x, y : lambda z : x + y + z
curry2 = lambda x : lambda y : lambda z : x + y + z
100〜のスレッドの続きを読む