クロージャって何がいいの？ [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2014/11/08(土) 13:11:47.84

関数型言語に必ずくっついてるこれ
いらんでしょ？匿名クラスで充分でしょ

**デフォルトの名無しさん** · 2014/11/19(水) 23:00:05.80

クロージャばりばり使うlisp方言でもwith構文は使うよ

**デフォルトの名無しさん** · 2014/11/19(水) 23:12:18.42

クロージャとクリーンアップ処理とは別の話じゃないの？

**デフォルトの名無しさん** · 2014/11/19(水) 23:33:41.68

Pythonが憎すぎて既知外になった人の相手をしちゃいけません

**デフォルトの名無しさん** · 2014/11/19(水) 23:39:01.13

>>150
> なおJavaScript はクロージャと with 構文のどちらも持っているけど、
> 書籍 "JavaScript: Good Parts" だとクロージャは Good Parts に
> with 構文は Bad Parts に分類されている

お前バカじゃね？大馬鹿じゃね？

ここで言ってるwithは例外が起きた時にリソースを解放する機能を持ったもの。
JavaScriptのwithはそんな機能は持っておらず、

obj.foo() を
with(obj) {
　　foo()
}
と書けるようにするためでしかなく、それによる問題（詳しくは調べて）があるから
Bad Partsになってるだけ。
PascalやPythonのwithがBad Partsになってるわけじゃない

お前、ほんと、馬鹿だよね？

**デフォルトの名無しさん** · 2014/11/19(水) 23:57:41.67

クロージャと with 構文のどちらも持っている言語であれば、
ケースバイケースで可読性や好みで使い分ければいいのではないかと

問題はクロージャを持たない、あるいは
「世間一般のクロージャの要件(>>104)」を満たせない言語では、
with 構文という(クロージャと比べて)不自由な代用品を使わざるをえない
という話

**デフォルトの名無しさん** · 2014/11/20(木) 00:02:30.91

>>150 >>155
下の(a)と(b)が等価であるようなJSのwith構文と
リソース解放のwith構文の区別もつかないような馬鹿が
何書いても説得力無いよ

// (a)
with (obj) {
    a = b;
}

// (b)
if (obj.a === undefined) {
    a = obj.b === undefined ? b : obj.b;
} else {
    obj.a = obj.b === undefined ? b : obj.b;
}

withって字面だけ見て同じだと思っちゃったの？
そんなだから構文の字面しか見てない馬鹿って言われちゃうんだよ

**デフォルトの名無しさん** · 2014/11/20(木) 00:19:03.39

>>154
>ここで言ってるwithは例外が起きた時にリソースを解放する機能を持ったもの。

わざわざ with という構文を追加して言語の意味論を複雑にしなくても、
もし汎用的な概念であるクロージャがあれば、同じ事を実現できるってことだよ

もし Python にもクロージャがあるなら、他の言語達と同様に
with 構文を使わなくてもリソースの自動解放を簡潔に表現できるハズだけど、
手続き型言語の Python では無理だろうね

それとも、書けるかな？

**デフォルトの名無しさん** · 2014/11/20(木) 00:20:15.54

pythonでも引数にクロージャ受け取ってwithの中でそれを実行する関数つくれば、rubyのそれと等価じゃね？
pythonはlambdaが制限きついから複雑な処理はインラインには書けないけど。

**デフォルトの名無しさん** · 2014/11/20(木) 00:29:37.23

>>158
>それを実行する関数つくれば、

もし Python が「世間一般のクロージャの要件(>>104)」を満たしていれば、
「関数をつくらなくても」クロージャだけで簡潔に書けるはず
つまり「関数をつくらなければ書けない」ということは、
Python が「世間一般のクロージャの要件」を満たしていないことを認めたってこと

**デフォルトの名無しさん** · 2014/11/20(木) 00:36:40.77

「世間一般のクロージャの要件」が
全然世間一般の定義じゃない件

**デフォルトの名無しさん** · 2014/11/20(木) 00:37:00.07

>>159
def make_f(x):
　def f(y):
　　return x * y
　return f

例えばこんなのがあったとして、このmake_f()が返すものは何？

**デフォルトの名無しさん** · 2014/11/20(木) 00:42:39.12

>>161
「クロージャみたいなモノ」もしくは「クロージャもどき」

def make_f(x):
　return lambda(y): x * y

が返すのも同じ

**デフォルトの名無しさん** · 2014/11/20(木) 00:44:55.24

>>162
「クロージャみたいなモノ」もしくは「クロージャもどき」と、クロージャの違いは何？

**デフォルトの名無しさん** · 2014/11/20(木) 00:45:40.70

>>162
>>31の定義だと完璧にクロージャの条件を満たしてるけど？

君はどこのローカルルールの話をしてるの？

**デフォルトの名無しさん** · 2014/11/20(木) 00:47:27.27

>>163
>>104

**デフォルトの名無しさん** · 2014/11/20(木) 00:52:13.60

>>165
＞世間一般のクロージャの要件（C#、Java8、C++11、JavaScript、Ruby 等々）：
＞　関数であっても無名関数であっても、局所環境を持つ(変数を束縛できる)：>>52,56,77

>>161のmake_f()が返すものは局所環境をもってるし名前も付いてないよ。

**デフォルトの名無しさん** · 2014/11/20(木) 00:58:03.79

>>164
いや、Python は関数を定義しなければ局所環境が作られないんだから、
>>31 の要件は満たしていないだろ
>>31 には「ラムダ式や無名関数で実現している」と書かれているんだけど、
日本語が不自由なんですか？

実際、もしも >>31 の定義を満たしているなら、
>>46 のゴチャゴチャしたコードは
(>>73 のようにわざわざ関数を定義しなくても)
>>83 のように「ラムダ式や無名関数で実現している」
簡潔なコードに書き直せるはずだ

さて、論よりコード、>>164 は書き直せるかな？

**デフォルトの名無しさん** · 2014/11/20(木) 01:00:19.64

今の議論と全然関係ないんだけど、久しぶりにTIOBEを見たら
ちょっと前までPerl, Python, Ruby, PHPで順位を争ってたのに
いつの間にかRubyだけ人気無くなっててワロタw

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

だからRuby信者発狂しちゃったの？

1 C
2 Java
3 Objective-C
4 C++
5 C#
6 PHP
7 Python
8 JavaScript
9 Perl
10 Visual Basic .NET
11 Visual Basic
12 R
13 Transact-SQL
14 Ruby
15 Delphi/Object Pascal
16 F#
17 PL/SQL
18 Swift
19 Pascal
20 Dart

**デフォルトの名無しさん** · 2014/11/20(木) 01:03:38.95

>>167
>>31には「いくつかの言語では」と前置きされてるじゃん
つまりラムダ式や無名関数は必要条件ではない

そっちこそ日本語が不自由すぎるのでは？

**デフォルトの名無しさん** · 2014/11/20(木) 01:04:53.19

>>166
それは def f(x): で関数を定義しているから、当たり前の話

「世間一般のクロージャ」であれば、わざわざ関数を定義しなくても
ラムダ式や無名関数と呼ばれる構文でクロージャを作れるんだよ
>>31 をよく読み直そうね

**デフォルトの名無しさん** · 2014/11/20(木) 01:06:05.89

>>170
じゃあさ、これが返すものは何？
(define (make_f x)
　(define (f y)
　　(* x y))
　　f)

**デフォルトの名無しさん** · 2014/11/20(木) 01:07:50.18

>>170
> >>31 をよく読み直そうね

お前が100回読み直した方が良いぜw

**デフォルトの名無しさん** · 2014/11/20(木) 01:10:58.55

>>169
>>31　にある「いくつかの言語では」という前置きは、
後から出てくる Smalltalk や Ruby のブロック構文を指すと
考えるのが自然じゃないかな？

さすがに Wikipedia のページ著者が
「ラムダ式や無名関数」と「関数定義」との違いも
分からないほどのお馬鹿さんだとは思えないしね

**デフォルトの名無しさん** · 2014/11/20(木) 01:11:10.32

>>171
ごめん。それで (make_f 10) とか実行した時に返ってくるもの、の間違い。

**デフォルトの名無しさん** · 2014/11/20(木) 01:15:12.19

>>171
クロージャだね

(define (make_f x)
　(lambda (x) (* x y))
)

が返すのもクロージャだね

**デフォルトの名無しさん** · 2014/11/20(木) 01:18:52.68

>>175
>>161のpythonのコードと完全に同じなんだけどw

**デフォルトの名無しさん** · 2014/11/20(木) 01:18:56.43

>>173
> さすがに Wikipedia のページ著者が

Wikipediaの編集者を持ち上げるのは良いけど、
お前の主張とは違う事が書いてあるぜ
読めるか？Pythonって書いてある

> クロージャを持つ言語に、C# 3.0、C++11、ECMAScript（JavaScriptを含む）、Groovy、Java 8（予定）、
> Perl、Python、Ruby、PHP（5.3以降）、Lua、Squirrelなどがある。

**デフォルトの名無しさん** · 2014/11/20(木) 01:28:21.39

>>177
Wikipedia の記事が常に 100% 正しいと思っているのかな？

記事の冒頭にある >>31 のクロージャという用語の定義とは
矛盾していると思うけどね
（自分のクロージャという用語の定義は >>4 で書いた）

もし矛盾していないと反論したいのなら、論よりコードだ
>>46 のゴチャゴチャしたコードは
(>>73 のようにわざわざ関数を定義しなくても)
>>83 のようにラムダ式や無名関数だけで書き直せるはず

さて、>>177 は書き直せるかな？

**デフォルトの名無しさん** · 2014/11/20(木) 01:32:42.88

>>178
>>169が正解と考えれば全く矛盾してないので、お前が間違ってるんだよ

**デフォルトの名無しさん** · 2014/11/20(木) 09:44:37.50

with構文はスコープから抜ける時にclose的な関数を必ず呼び出してくれる保証があるけど、
Rubyのブロックにはそんな保証は無い
だからRubyではウッカリcloseを忘れても分かりにくい
そういうのは良くない

**デフォルトの名無しさん** · 2014/11/20(木) 11:08:08.37

>>178
> Wikipedia の記事が常に 100% 正しいと思っているのかな？

思ってないけど、あんたが言っていることよりかは
正しいと思うね。

だって、あんたの言うことのほうが正しいなら
wikipediaを修正すればいいわけだから。

**デフォルトの名無しさん** · 2014/11/20(木) 12:57:07.44

なんだ、この偏執狂たちの罵り合いはw

そんなことより、問題。
若い内に買ってでもしろ、と言われるものはなぁんだ？

**デフォルトの名無しさん** · 2014/11/20(木) 15:15:51.24

ああ、let-inが無いからpythonのはクロージャじゃないって主張か。
斜め上だな。

**デフォルトの名無しさん** · 2014/11/20(木) 16:40:50.21

環境と変数を手軽に包めるのは有難いけどなあ
XMLベースのジョブ管理言語とか
ちょっとしたVM作るときに
継続の表現にクロージャなしだとだるいよ
さらに無名クラスも無い言語だと
本物のVM作らなきゃいけなくなる

**デフォルトの名無しさん** · 2014/11/20(木) 20:12:20.93

https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Closures

**デフォルトの名無しさん** · 2014/11/21(金) 13:07:27.23

>>182
セックス…かな
年とると立たなくなるから

**デフォルトの名無しさん** · 2014/11/21(金) 13:13:28.47

>>186
ご愁傷さまです。

**デフォルトの名無しさん** · 2014/11/29(土) 13:01:53.24

>>188
？

**デフォルトの名無しさん** · 2014/12/10(水) 19:56:15.27

Swift スレでクロージャの話題で荒れそうだったので、こちらへ移動しとく
　http://peace.2ch.net/test/read.cgi/tech/1415860741/153

--
Swift や Ruby を含む多くの言語では常識であるけど Python では異なるものとして、
関数型言語に由来した(無名関数やラムダ式とも呼ばれる)クロージャがある
たとえば "The Swift Programming Language" の "Closure" の章にある map メソッドを使った
サンプルコードは、Ruby でも同じスタイルの良く似たコードで書き直せる：
　http://ideone.com/TsGD6B
これは Ruby だけでなく、JavaScript でも同じ
Swift や Ruby と比べて構文が簡潔な JavaScript ではいくらか冗長にはなるけれど、
何の苦もなく Swift と同じスタイルで書き直せる：
　http://ideone.com/74oNVU

同様に、「あるテーブルから特定の行だけを抽出し、加工して、集計する処理」は、
Swift だと table.filter { .... }.map { .... }.reduce { .... } とメソッドを連結(チェイン)させた式で書ける
これは Ruby なら table.select { .... }.map { .... }.inject { .... } と書き直せる
ここで、クロージャ内の ..... の部分には、上記のサンプルのように「任意の文(statements)が書ける」

もしかすると、いやこんなの高階関数のプログラミングを知っている人なら当たり前だろ、と感じるかもしれない
ところが Python だけはクロージャの本体に(任意の文ではなく)「式(expression)しか書けない」：
　http://ideone.com/tDaDkL　　# --> Syntax Error になってしまう
だから、他の言語のクロージャに相当するコードを(名前のある)関数としてわざわざ宣言しなければならない：
　http://ideone.com/R7twCQ

結果として、Python は手続き型プログラミングであれば簡潔で可読性に優れたコードが書けるスクリプト言語だけれど、
関数型プログラミングには適さず、こうした関数型プログラミングは推奨されていないらしい(これを "酸っぱい葡萄" と言ふ)
　http://peace.2ch.net/test/read.cgi/tech/1345123070/70-71

これが Swift や Ruby 等と比較すると、関数型プログラミングで Python が劣る典型的な一例になる

**デフォルトの名無しさん** · 2014/12/10(水) 20:24:01.24

と言うかどう見てもこないだまでこのスレに居た俺俺定義の人ですな

**デフォルトの名無しさん** · 2014/12/10(水) 20:43:29.64

よく見たら、そのスレで誘導かけてるの、話振ったお前本人じゃねーかw
俺俺定義が認められなかったから逃げて来たのか？

**デフォルトの名無しさん** · 2014/12/10(水) 21:30:40.85

クロージャの定義は>>4って書かれてたがStandard MLにラムダ式はない
けど当然SMLにはクロージャがあるわけで
ソースはThe Definition of Standard ML, revised edition

**デフォルトの名無しさん** · 2014/12/10(水) 21:46:37.74

関数型プログラミングってどういうのを指して言ってるんだろ

**デフォルトの名無しさん** · 2014/12/10(水) 21:50:32.14

>>189のサンプルが手続き型全開の書き方で笑った

>>193
関数（に名前付けたくない）型プログラミング

**デフォルトの名無しさん** · 2014/12/11(木) 21:30:20.83

>>191
Swift スレの質問「Python が Swift や Ruby より劣ってるのは何か」に答えただけ
で、具体的に反論できないから罵倒を始めて Swift スレが荒れそうだったから、
こちらへ移動してきた

>>192
>>4 の定義において、局所環境やラムダ式は(クロージャという概念の構成要素であるけど)、
一般の言語だと直接的に対応する具象構文として存在していない(自分は知らない)
その書籍は読んでいないけど、おそらく Standard ML では "fn" <match> という具象構文を
「関数(function)」または「関数式(function expression)」と呼んでいると思う
で >>4 だと、その具象構文 "fn" <match> はクロージャに対応する

またクロージャ(日本語では「閉包」)という用語は馴染みづらいので、
クロージャの具象構文を指して(便宜的に)無名関数/匿名関数/ラムダ関数/ラムダ式/関数式 ...etc と
別名で呼ばれることがある：
・Standard ML では、単純に「関数」や「関数式」と呼ぶ
・JavaScript では、"ECMAScript Specification" では(SML と同様に)「FunctionExpression」と呼ばれ、
　サイ本では「関数リテラル」と呼ばれている
　　・13 関数定義 (Function Definition) -- Under Translation of ECMA-262 3rd Edition
　　　　http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/13_Function_Definition.html
・Python では、その言語リファレンスで「ラムダ式」と呼ばれている：
　　・6. 式 (expression) ― Python 3.4.2 ドキュメント
　　　http://docs.python.jp/3.4/reference/expressions.html#lambda

**デフォルトの名無しさん** · 2014/12/11(木) 21:48:16.84

>>195
肝心のクロージャの定義の引用はまだですか？
俺俺定義はお腹いっぱいなんですよ

**デフォルトの名無しさん** · 2014/12/11(木) 22:44:15.05

調べてみると、Python のラムダ式で任意の文が書けないという問題(>>189)は、
過去に何度もネット上で話題になっていたようだね：
・Is it possible to have multiple statements in a python lambda expression? - Stack Overflow (May 14 '09)
　http://stackoverflow.com/questions/862412/is-it-possible-to-have-multiple-statements-in-a-python-lambda-expression
・syntax - No Multiline Lambda in Python: Why not? - Stack Overflow (Aug 5 '09)
　http://stackoverflow.com/questions/1233448/no-multiline-lambda-in-python-why-not
・Why doesn't Python allow multi-line lambdas? - Programmers Stack Exchange (Aug 7 '11)
　http://programmers.stackexchange.com/questions/99243/why-doesnt-python-allow-multi-line-lambdas

そして、この問題を解決すべく数多くの提案が出された：
・AlternateLambdaSyntax - Python Wiki
　https://wiki.python.org/moin/AlternateLambdaSyntax

それら提案の中には、Ruby のブロックを真似しよう(similar to Ruby's blocks)、というものまであった
・[Python-ideas] Proposal for function expressions - Grokbase
　http://grokbase.com/t/python/python-ideas/097ccjz2c3/proposal-for-function-expressions

しかし残念ながら、これ以上続けても収束しそうもないから議論は打ち切り、とGuido氏が宣言(強権発動？)して終わった
・[Python-Dev] Let's just *keep* lambda
　https://mail.python.org/pipermail/python-dev/2006-February/060415.html
この顛末をGuido氏は「複数行のラムダは解けないパズル(unsolvable puzzle)」と語っている
・Language Design Is Not Just Solving Puzzles
　http://www.artima.com/weblogs/viewpost.jsp?thread=147358

まさに「みんなを納得させるほどの「結論」じゃない」というのは、こういう状況を指しているんだろね....
　http://peace.2ch.net/test/read.cgi/tech/1417333026/9

**デフォルトの名無しさん** · 2014/12/11(木) 22:55:21.60

>>189
普段Python書かないからPythonicではないかもしれないが、だいたいこんな感じだろう。
http://ideone.com/0vAET2

それで、何が問題なんだ？

**デフォルトの名無しさん** · 2014/12/11(木) 23:02:23.22

>>196
ではクロージャ定義の引用元ソースを示そうね

答えは書籍「計算機プログラムの構造と解釈」、いわゆるSICP本だ
その中の節「3.2.1 評価の規則」に手続きオブジェクトが、いわゆるクロージャに対応する
　http://sicp.iijlab.net/fulltext/x321.html

そしてクロージャを視覚化したのが、
このページの図3.2にあるオタマジャクシの卵が２つ並んだ図形になる

単純な話だと思うけど、難しいかな？

**デフォルトの名無しさん** · 2014/12/11(木) 23:27:50.83

>>198
関数を宣言せずに書くという制約の元ですから、とてもPythonらしいコードだと思います
しかもループの代わりに関数再帰を使っているのですから、より関数型プログラミングらしいとも言えます

ただし、元々 Swift で書かれていたサンプルコードを各 LL へと書き直しているのですから、
もし以下の点を改善できれば(Pythonらしさという意味では)完璧でしょう：
・中間変数 f を宣言せず、リスト内包式の中にラムダ式をインラインで書く
・Swift のコードは辞書を使っているのですから、それを(勝手に)配列 digits へ改変せず、
　Python でも(Ruby や JavaScript と同様に)辞書を使って書く

**デフォルトの名無しさん** · 2014/12/12(金) 00:10:51.51

>>200
注文が多いな。
http://ideone.com/KWnSgA

**デフォルトの名無しさん** · 2014/12/12(金) 09:01:50.64

>>199
で、どこに「クロージャは無名関数でなければダメ」と書いてあるの？
「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが？

いい加減、誤摩化して逃げ回るのは止めたら？

**デフォルトの名無しさん** · 2014/12/12(金) 19:05:12.73

別にPythonのラムダに式が書けないから問題だと言うだけなら荒れねーよ
そこで「だからPythonにはクロージャが無い」って言う
決して成り立たない等式を持ち込むから「いやそのりくつはおかしい」って言われてんのに
そしたら既存のクロージャという用語の定義のほうを弄ろうとするから叩かれてんだろうが

プログラミングに例えるなら、お前は自分の書いた関数で
組み込み整数型の値にそのままリスト処理を適用しようとして例外吐かれたから、と
整数クラスのほうがリストとして振る舞うようにメソッドを書き換えようとしてる

**デフォルトの名無しさん** · 2014/12/12(金) 22:20:24.14

>>201
お疲れさまです
中間変数 f は消えましたが、今度は中間変数 applyf が現れてしまいましたね....

**デフォルトの名無しさん** · 2014/12/12(金) 22:38:08.46

>>204
http://ideone.com/zAN4uA

**デフォルトの名無しさん** · 2014/12/12(金) 22:42:02.66

>>204
とりあえずクロージャの定義を貼っておきますね
反論よろしく

https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Closure_(computer_science).html

> In computer science, a closure is a first-class function with free variables that are bound in the lexical environment.

ここの文章も良く読んでね

> The term closure is often mistakenly used to mean anonymous function.
> This is probably because most languages implementing anonymous functions allow them
> to form closures and programmers are usually introduced to both concepts at the same time.
> These are, however, distinct concepts.

**デフォルトの名無しさん** · 2014/12/12(金) 23:33:45.85

>>202
> で、どこに「クロージャは無名関数でなければダメ」と書いてあるの？

もちろん「クロージャは無名関数でなければダメ」とは書かれていない
同時に「ラムダ式に文が書かなくともクロージャである」とも書かれていない
SICP本を理解するには、記述されている定義から類推によって解釈できる知性が必要だね

>「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが？

この節で記述されているのはクロージャの一般的な概念であり、特定の言語や実装には限定されない
ここで記述されている概念に沿って設計された言語であれば、たとえば：
・Scheme なら (lambda (x) .... ) で、
・Standard ML なら fn x => .... で、
・JavaScript なら function(x) { ..... } で、
・Ruby なら proc { |x| .... } で作られる
ここで.... の部分には、破壊的代入や入出力等の副作用を伴う任意のコードが書ける
唯一、書けないのは Python だけ

で、どこに「Schemeという特定の言語」と書いてあるの？
いい加減、誤摩化して言い逃れをするのは止めたら？

**デフォルトの名無しさん** · 2014/12/12(金) 23:54:36.75

>>205
ありがとうございます、これで完璧ですね

これで「何が問題なんだ？(>>198)」という議論を続けることができます
具体的には、>>189 の Swift/Ruby/JavaScript で書かれたコードと
>>205 の Python で書かれたコードを比較して、
「どちらがわかりやすいか/読みやすいか/書きやすいか？」という話です

で、これらは主観による評価ですから、
いくら議論しても誰もが納得できる結論へとは収束しないでしょう
すべての Pythonista にとって >>205 が読みやすく書きやすいと感じるのなら、
それはそれでいいんじゃないでしょうか

**デフォルトの名無しさん** · 2014/12/13(土) 00:01:46.30

一時変数を消すためにそんなパズルみたいな事やって読みやすいわけないだろw

**デフォルトの名無しさん** · 2014/12/13(土) 00:13:09.40

>>207
schemeではlambdaが本質的なもので(define (f x) ～)はシンタックスシュガーだけど、
pythonではdefが本質的なものでlambdaの方がシンタックスシュガーなのでは。

**デフォルトの名無しさん** · 2014/12/13(土) 00:39:02.24

>>206
Wikipedia 英語版の解説と同じに見えるけど、何を言いたいのかな？
・Closure (computer programming) - Wikipedia, the free encyclopedia
　http://en.wikipedia.org/wiki/Closure_(computer_programming)
単に他人の文書をコピペして終わりにするだけでなく、引用した文書(ソース)を元に、
自分なりの意見を思考しそれを自分の文章として表現できるようになったほうがいいと思う

で、とりあえず反論しておくと、その文書(= Wikipedia)の
章「mplementation and theory」には、冒頭に以下の記述がある

> Closures are typically implemented with a special data structure that
> contains a pointer to the function code, plus a representation of
> the function's lexical environment (i.e., the set of available variables)
> at the time when the closure was created.

この理論としてのクロージャ定義は、SICP本(>>119) および >>4 のそれと矛盾していない
そして Haskell のような純粋関数型言語に限定した文脈ではないのだから、
文中の "function code" は(>>207 で書いたように)単なる式だけではなく
破壊的代入や入出力等の副作用を伴う任意のコードも書けると解釈するのが自然だと考える

**デフォルトの名無しさん** · 2014/12/13(土) 02:01:28.39

>>4
>クロージャを識別子に束縛したものが一般的な「関数宣言」である

よかった、pythonにもちゃんとクロージャあった

**デフォルトの名無しさん** · 2014/12/13(土) 02:13:23.84

foo = lambda bar: bar
これはクロージャである

っていうのが偽であることを定義から証明すればいいんじゃないかな
反例あげればいいだけだよね？

**デフォルトの名無しさん** · 2014/12/13(土) 02:17:02.89

あ、まちがえたそれはクロージャじゃない
def foo():
bar = 1

これに訂正

**デフォルトの名無しさん** · 2014/12/13(土) 07:14:46.97

>>208
それはPythonの書き方じゃないんだよ。
お前が>>200で指定したから、結果的にそうなっただけで。

それで、結局「クロージャを書けない」から「読みにくい」に問題をすり替えて終わりか？

**デフォルトの名無しさん** · 2014/12/13(土) 08:00:50.00

http://ideone.com/C5hOIB

**デフォルトの名無しさん** · 2014/12/13(土) 10:42:15.83

イデオンこわい

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 12:26:47.45

>>207
> もちろん「クロージャは無名関数でなければダメ」とは書かれていない

なんだ、Pythonのdefで良かったんだ

知らないみたいだから教えてあげるけど、Pythonではdefで関数定義すると
環境を持ったクロージャになってるんだよ、勉強になったね

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 12:40:53.92

>>208
>>201のapplyfは、特定のロジックに依存しない汎用的な関数だけど、
こういうものの定義や使用も認めないってことは
ライブラリによる拡張も否定するってことでOK？

ライブラリを使わないと外部イテレータが使えないRubyをdisってるの？

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 14:05:13.26

>>207
書かれてない要素を勝手に追加するから
オレオレ定義って言われるんだよ

クロージャの定義には無名関数であることも、文が書けるor書けないことも、
含まれてないんたから、勝手に条件に追加すんな

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 14:39:36.41

>>217
>>216 はPythonのlambdaからでも副作用を伴うメソッド呼べますよってコードだな

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 20:13:18.59

>>210
本質という言葉の定義が曖昧ですが、自分なりにコメントします

まず >>206(= Wikipedia, >>211)の章「2.1 First-class functions」には、
その冒頭に以下の記述があります

> Closures typically appear in languages in which functions are first-class values ―
> in other words, such languages enable functions to be passed as arguments,
> returned from function calls, bound to variable names, etc.,
> just like simpler types such as strings and integers.

つまりクロージャは「一級の値( first-class values)」であると定義しています
従って(一級市民ではない関数宣言 def よりも)一級市民であるクロージャ lambda を
本質とするのが正しいのではないかと思います
（「宣言された関数は一級市民だけど、宣言そのものはそうではない」という意味です、念の為）

(あくまで私見ですが)可能性があるのは、関数スコープ方式の手続き型言語である Python では、
関数型言語の特性を追加する際にクロージャを(lamda ではなく)宣言された関数へ実装したほうが
(開発工数や難易度の視点からは)容易だったのではないかと推測します（詳細は省略....）
一言で言えば「Python は手続き型言語だから」ということですね

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 20:39:14.11

>>222
本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。

first-class valueってのは、変数に代入したり、関数の引数に渡したり、
関数の値として返したりできるオブジェクトの事だよ。
def だの lambda だのっていうのはそういうオブジェクトであるクロージャを作り出すための構文だよ。

pythonは手続き型言語だっていうけど、そんなの当たり前だろw
rubyだのjavascriptだのだって手続型言語だよ。

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 21:42:39.17

>>223
> 本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。

その意味であれば、関数型言語と Ruby/JavaScript だと
関数定義よりもクロージャのほうがが本質的だね
プリミティブな名前とクロージャから関数(or メソッド)が作られるという
因果関係があるのだから

ただし、Python だけは違うみたいだね

> rubyだのjavascriptだのだって手続型言語だよ。

外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている
だから最初から関数型言語と同等なクロージャを備えて誕生した
それが知られるようになったのは最近だから、知らない人は多いけどね.....
手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ
　http://peace.2ch.net/test/read.cgi/tech/1409526637/857

--
> パクリどころか Ruby と JavaScript は、これらの作者自身が
> Lisp を基礎として言語を設計したと語っている
>
> ・Lisp から Ruby への設計ステップ
> 　http://yohshiy.blog.fc2.com/blog-entry-250.html
> ・JavaScript: The World's Most Misunderstood Programming Language
> 　http://www.crockford.com/javascript/javascript.html
> （邦訳版「JavaScriptの勉強：世界で最も誤解されたプログラミング言語」へのリンクは閉鎖）
>
> だから関数型プログラミングという土俵の上で Ruby や JavaScript に
> 手続き型言語の Python がいくら挑戦しても勝てずに負け続けているのは、
> しごく当然な結果なわけ

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 22:07:55.30

＞外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている

S式で表現されてなきゃlispじゃねえよ。

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 22:14:57.19

だいたいlispが関数型言語だって言うことにも抵抗がある。

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 23:06:18.71

>>224
>手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ

自己レスで補足する（すべての手続き型言語が Python と同じではない....

同じ手続き型言語に関数型の特性を追加した言語でも、
調べた範囲だと少なくとも Perl5/Java8/C++11 のクロージャは
・>>4,>>119 のクロージャ定義に沿って設計され、
・クロージャ内で任意の文が書ける
ただしそれら言語がクロージャをサポートした時期は遅かった
真面目に設計したからだろう

対して Python の関数型サポートは素早かったけど、検討が不十分だったと言うほかない
リリース後に改善要望/議論紛糾したあげく、結論を出せず現在に到る(>>197)

**名無しさん＠そうだ選挙に行こう** · 2014/12/13(土) 23:27:26.05

横だけど、
Rubyのブロックはラムダじゃないしファーストクラスでもないよね
？
メソッドにラムダを渡すこともできるけど、不格好なんだが？
これって、ここのオレオレ定義にてらすとどうなの？

なんだか、ラムダに文を書けない（書かない）ようにしている
Pythonの仕様をあげつらうためだけにオレオレ定義をこねくって
悦に入ってるPythonアンチがいるって感じがするだけなんだが。

**デフォルトの名無しさん** · 2014/12/14(日) 00:01:22.20

Rubyのブロックの中に副作用をジャンジャン書いて
それを繋げるスタイルを関数型と言われても困るわ

文推奨の時点で関数型とは言い難いわけだし

**デフォルトの名無しさん** · 2014/12/14(日) 00:38:38.65

オレオレクロージャ君は言葉が通じないし、
必死でググった的外れで糞長い引用でしか反応しないし、
相手するだけ無駄。

**デフォルトの名無しさん** · 2014/12/14(日) 02:05:45.83

うん、ただのPythonアンチでしか無いと思うよ。
Ruby好きでPython嫌いな俺は、Pythonのlambdaが使いにくいのには同意するが
そのためにクロージャの定義のほうを捻じ曲げるのは、ありえないと感じるよ。
そもそも、その定義だとRubyどーなんねん、と思うし。

Rubyには「他言語の関数」に相当するものがなく、
一定の条件を満たし、見かけ上、関数のような呼び出しが可能なメソッドを
便宜的に「関数」と呼んでいるだけだし。

クロージャはブロックという形で存在はしているが、
彼の言う定義に従うならブロックはファーストクラスでなければならない。
でもRubyのブロックはファーストクラスとは言い難い。
lambda関数(実際はもちろんメソッド)が返すのはProcクラスのインスタンスだけれども、
ブロック.is_a? Procインスタンスでは無い。そしてメソッドや、ましてや関数でもない。
そもそもブロック単体では値としては取り回せないからProcクラスがあるんだし。

**名無しさん＠そうだ選挙に行こう** · 2014/12/14(日) 10:29:16.99

オレオレクロージャ君って少し前に某スレでPython disってた人にそっくり

**名無しさん＠そうだ選挙に行こう** · 2014/12/14(日) 14:05:17.21

lambda

ラ…ランバダ…

**名無しさん＠そうだ選挙に行こう** · 2014/12/14(日) 14:52:29.83

>>233
もっと勇気をもって！
ランバダ！

**名無しさん＠そうだ選挙に行こう** · 2014/12/14(日) 15:49:06.80

　　　　　　　,-----、
　　　　　　/　　　　ヽ.
　　　　　　|　(･)　(･) |
　　／ヽ￣　　　　　　￣ﾉヽ
　/　　ヽ＿＿＿＿＿/　　ヽ
　|　　　/　　　　ｌ　　　|　　　 |＼
　|　　　|　　。ノ　ヽ。 .|＿＿_|　＼
　ヽ＿__ヽ　　　 +　　ﾉ,､_､_､_ヽ　　＼
　　|　　ヽ|￣￣￣￣ |　;;;;;;;;;;;;;;;＼＿ﾉ
　< ````/＼　　　／＼;;;;;;;;;;;;;;;;;/
　　ヽ;;;;;;|　　＼＿/　　　ヽ;;;;;;;;;;;ﾉ
　　　￣.|＿__/ 　　＼＿＿)￣　 .＿＿__
　　　　/　　 |　　　　|　　 |　　　　＼　／
　　　（＿＿_|　　　　|＿＿）＝＝＝⊃

　　　　　　勇者の父　ランバダ

**名無しさん＠そうだ選挙に行こう** · 2014/12/14(日) 15:54:41.51

無駄にMP消費していざという時に足りなくなって犬死にする無能

**デフォルトの名無しさん** · 2014/12/14(日) 20:48:34.17

>>228
>Rubyのブロックはラムダじゃないしファーストクラスでもないよね？

Python や JavaScript のクロージャは、(名前が宣言された)関数と同様に
クロージャへ引数を渡すだけで評価される
　　closure = function(x) { return x + 1 }　　# クロージャを生成して名前に束縛
　　succ_of_one = closure(1)　　# クロージャを評価
それに対して Ruby だと、メソッド Proc#call を呼ばなければ評価されない
　　block = lambda { |x| x + 1 }　　# ブロックを生成して名前に束縛
　　succ_of_1 = block.call(1)　　# ブロックを評価
従って >>4(>>199) の関数型言語におけるクロージャ定義に当てはめれば
「Ruby のブロックは(本物の)クロージャではない」あるいは「....はクロージャもどきである」
またRuby のブロックの意味はオブジェクト(Procクラスのインスタンス)だからファーストクラスである

>メソッドにラムダを渡すこともできるけど、不格好なんだが？

たしかに不格好だ
　def foo(x, y, &block); .... ; end　　# メソッドを定義
　foo(x, y, lambda { |z| .... })　　# メソッドの呼び出し
だから Ruby には「ブロック付きメソッド呼び出し」という構文糖が最初から用意されている
　def foo(x, y); .... ; end　　# メソッドを定義
　foo(x, y) { |z| .... }　　# メソッドの呼び出し

>Pythonの仕様をあげつらうためだけにオレオレ定義をこねくって

>>4 のクロージャ定義の引用元(ソース)は >>199 で示したが、まともな反論はない
むしろオレオレ定義と騒ぎ立てていた連中がSICP本を読んだ事もないお馬鹿達だったのでは？
あるいはSICP本を読んでいなくても、関数型言語の操作的意味論や処理系実装の知識があれば
>>4 がオレオレ定義でないことは直ぐに理解できていたはず

**デフォルトの名無しさん** · 2014/12/14(日) 21:10:51.70

>>237

後から言い逃れようとしても、掲示板にはログが残ってるから無駄ですよ
>>98に対する>>102の返答の時点で、何も分かってなかったのは明らか

**デフォルトの名無しさん** · 2014/12/14(日) 21:42:31.25

>>237
RubyのブロックはProcクラスのインスタンスではないよ
ブロックそのものは、メソッド呼び出し文法の一部でしかない
そのブロックを、それのみで値として扱うためのラッパがProc

**デフォルトの名無しさん** · 2014/12/14(日) 21:59:53.72

Rubyistは全員クロージャを間違った解釈してるのか？
それとも、奴だけなのか？

そこが気になるな。

**デフォルトの名無しさん** · 2014/12/14(日) 22:03:54.59

>>229
残念ながら Ruby の関数型プログラミングというスタイルは、
全世界の Ruby コミュニティですでに認知されている
・Functional programming with Ruby
　http://code.google.com/p/tokland/wiki/RubyFunctionalProgramming　
・Rubyによる関数型プログラミング（上記文書の日本語訳）
　www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html
また Ruby の「ブロック付きメソッド呼び出し」とそれらを並べる(=チェーンさせる)スタイルは、
Apple の新言語である Swift にそのまま採用された
他の言語、たとえばラムダ式が導入された Java 8 だと、このスタイルをストリームと呼んでいる
・ラムダ式で本領を発揮する関数型インターフェースとStream APIの基礎知識 (2/3) -- @IT
　http://www.atmarkit.co.jp/ait/articles/1404/30/news017_2.html

個人的には、Ruby と多くのOOP言語で採用されているメソッドチェーン・スタイルは：
・データの流れ(いわゆるデータフロー)とメソッドの並びが一致し、
・カッコが入れ子にならない
から、可読性が高いと思う
　table.select { |r| .... }.map { |r| .... }.inject(0) { |n, r| .... }　　# >>189 を参照
それに対して、Python 伝統的な関数適用スタイルでは：
・データの流れ(いわゆるデータフロー)とメソッドの並びが逆転し、
・カッコが入れ子になる
　reduce(lambda n, r: ...., 0, map(lambda r: ...., filter(lambda r: ...., table)))
どちらを優れているか？という評価は主観だから、各自で判断してもらいたい

（まだ続くので、ここで切る）

**デフォルトの名無しさん** · 2014/12/14(日) 22:48:49.10

>>238
次に、関数型プログラミングと(文の評価によって起こる)副作用との関連について

まず関数型プログラミングで副作用は推奨されていない
基本的には map/filter/reduce (Ruby では map/select/inject) といった高階関数を使った
(副作用の無い)参照透明性のあるコードが推奨されている
これは >>241 の文書「Rubyによる関数型プログラミング」で具体的なコード例を使って解説されている

おそらく誤解したのは >>189 の Swift/Ruby/JavaScript コードで while 文と
ローカル変数への破壊的代入を用いていたのを見たからだと思うけど、
これは、「わざわざ」副作用を使った手続き型プログラミングほうが簡潔になる「お題」を選んだからだ
実際、副作用の代わりに再帰を使った Python コード >>205 は「普通のプログラマ」には分かりにくい
（Python だけでなく、この「お題」は Ruby であっても再帰を使えば同じく分かりにくいコードになる）

また(Ruby を含む)大半の手続き型言語処理系だと、TCO(末尾再帰最適化)は実装されていないか不完全である
だから手続き型言語における関数型プログラミングにおいて、
再帰プログラミングには(分かりづらいだけでなく)実用上の制限があるから
ツリーのような再帰的データ構造の探索問題などに限定して利用すべき（上記文書の節「再帰」を参照）

これらの判断について、上記の文書では以下のように記述されている(節「おわりに」から引用)：
　「Rubyは基本的には命令型言語であるけれど、関数型プログラミングへの際立った潜在能力があるのだから、
　　それらをいつどのように使うか(そして、いつ使わないか)を知っておくべきである。」

**デフォルトの名無しさん** · 2014/12/14(日) 22:59:19.75

もうみんなgaucheに改宗しようぜ

**デフォルトの名無しさん** · 2014/12/14(日) 23:34:55.92

>>231
>Rubyには「他言語の関数」に相当するものがなく、......

これは(>>237 に書いたけど)、まったくそのとおり

>でもRubyのブロックはファーストクラスとは言い難い。

ここの「....とは言い難い」という文章表現は曖昧だね
（なぜ「....ではない」と断定的に言い切れなかったのだろうか？）

まず >>237 で書いたように、Ruby の「ブロック付きメソッド呼び出し」は構文糖だ
（対して、簡潔な構文を追求した Smalltalk では、常にブロックはオブジェクトである)
これを構文糖にした理由の一つはメソッド呼び出しコードを簡潔にする目的(>>237)であるが、
ブロックを多用する Ruby のプログラミングスタイルでは、ブロックを評価するたびに
Procオブジェクトを生成していたのでは実行効率の面でオーバヘッドが大きいという理由がある
このためRubyインタプリタの内部だと、
ブロックは(重いオブジェクトを表すC構造体ではなく)専用の軽量なC構造体で表現されている

ただし、(たとえ内部表現が Proc オブジェクトと異なっていても)プログラマから見れば問題にならない
なぜなら、渡されたブロックをいつでも Proc オブジェクトへ変換できる構文糖が最初から用意されているから....
たとえば foo(x, y) { |z| .... } という「ブロック付きメソッド呼び出し」に対して(>>237)：
・def foo(x, y); .... ; end
・def foo(x, y, &block); .... ; end
　という２つのメソッド定義は「いつでも」交換できる

まとめると：
　Ruby のブロックは内部表現だと Proc オブジェクトではないが、
　プログラマ目線ではファーストクラスのオブジェクトとして扱うことができる

**デフォルトの名無しさん** · 2014/12/14(日) 23:42:14.32

gaucheいいよね

**デフォルトの名無しさん** · 2014/12/14(日) 23:49:27.85

>>238
つまり「Ruby のブロックはクロージャである」という初歩的なミスについて、
>>102 をレスした時点から数えて >>228 が指摘するまでの間には
誰一人気付けなかった事実が「掲示板にはログが残ってるから明らか」になるわけですね

たいへんわかりやすいです

**デフォルトの名無しさん** · 2014/12/14(日) 23:57:54.55

最近はほぼgaucheでしかプログラム書いてない。
もう止められない体になってしまった。。。

**デフォルトの名無しさん** · 2014/12/14(日) 23:58:44.82

俺、numpyとscipyとopencvのサポートがgaucheにくっ付いたら、python捨てるんだ！(遠い目

**デフォルトの名無しさん** · 2014/12/15(月) 00:02:02.47

common lisp処理系の方が速いのあるしライブラリも充実してるし良いよ

**デフォルトの名無しさん** · 2014/12/15(月) 00:07:51.10

ループしないで全部再帰で書きたい