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

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

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

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

マジレスすると、クロージャーよりも
関数内関数の方がいい。

クロージャーは変数スコープが不必要に広い。

多くの場合、クロージャーの外は見える必要がない。
逆に見えてしまうと不用意に変数を書き換えてしまう。

関数内関数がない言語が多いから
仕方なくクロージャーを使うしかないが、
Java8のラムダの方がまだ安全なコードを書くことが出来る。
（ラムダも外のスコープが参照できる場合があるので完璧ではない）

つまり俺がいいたいのは、クロージャーを使うと苦労するのジャー。

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

ディスクロージャ

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

>>1
関数型言語の操作的意味論において、クロージャとは：
　　「ラムダ式と局所環境とを組合せた概念」
を指す
このクロージャを具象構文で表したものが一般的な「ラムダ式」であり、
クロージャを識別子に束縛したものが一般的な「関数宣言」である

Standard ML という関数型言語だと、
たとえばラムダ式は fn x => x + 1 であり、関数宣言は val succ = fn x => x + 1 である
ここで、関数宣言には fun succ x = x + 1 と簡潔に書ける構文糖を用いるのが一般的
だから、あらゆる関数型言語ないし関数型プログラミングが可能なあらゆる言語であれば、
クロージャ(という概念)は必要不可欠に存在である、と言える

また Java の「匿名クラス」もクロージャ(という概念)を応用した具象構文の一種である
で、Java 8 で導入された「ラムダ式」もクロージャの具象構文だけど、
匿名クラスよりも簡潔に書ける利点があるから、多くのケースで広く利用されるようになるだろう
両者の間には、局所環境と組み合わせる対象が「匿名クラス」ではクラスという単位であるのに対して、
「ラムダ式」では式という(クラスよりも粒の小さな)単位であるという違いがある
目的に応じて適切に両者を使い分けることが望ましい

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

　／￣￣￣￣￣￣￣￣￣￣￣￣￣＼
∠　　　　　　　　　　　　　　　　　　　　　ﾉ
　丶　　　　　　　　　　　　　　　　　　 |
　　ﾉ　　　　　　　　　　　　　　　　 |
　　|　　　　　　／￣￣￣￣＼　　　　 |
　　|　　　　　/　　　　　　ヽ　　　 |
　　|　　　　　|　　　　　　　 |　　　　 |
　　|　　　　　|　　　　　　　 |　　　　 |
　　|　　　　　|　　　　　　　 |　　　　 |
　/　　　　　 |　　　　　　　　　 |　　　 /
　ヽ　　　　　＼＿／| |＼＿／　　　　ヽﾍ
　　|　　　　　　　　／＼　　　　　　　　　/
　　￣￣￣￣￣￣　　　￣￣￣￣￣￣
　　　　　　　パンとか止めるやつ

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

>>5
それ、パンとか止めるやつだろ！

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

　　　　　　　　　　　　　　　　／￣￣＼
　　　　　　　　　　　　　　／ _ノ　ヽ､_ ＼
　　　　　　　　　　　　　.　|　（ ●）（● ）　|
　　　　　　　　　,-,-,-,__　|　　（__人__）　│rヽヽヽヽ__　　　「クイックロックバッグクロージャー！！」
　　　　　　　　r.l .' ' .'.r_l　| 　　｀⌒ ´ 　 . |　´l　　　.|/
　　　　　　　 .ヽ|　　　| 　 |　　　　　　 |　　|　　 /＿
　　　　　 ._,,-ーヽ　 /-‐ ヽ　　　　　　 /‐''",'　　/.　　｀ヽ
　　　　　/　　　/｀''‐-',.　　ヽ　　　　 ./　rj,.-‐''´｀l 　　./
　　　　　＼　　|　　二ヽ　　　　　　　　　　ヽ三　　|ー‐'´
　　　　　　｀''‐ヽ　 ―｀ﾍ　　　　　　　　 j ｀―r'´
　　　　　　　　　｀T ´ 　 j.　　　　　　 ./　　 j
　　　　　　　　　　ヽ　　 .ヽ、＿＿＿　 /　　 ,'
　　　　　　　　　　　 |　　 .／(＞)＾　ヽ＼　　 i
　　　　　　　　　　　 |　 .／　(＿　（＜）＼ .i　　
　　　　　　　　　／ .! ./　　 /rｪヾ__）⌒:::　ヾ.＼
　　　　　　　　 /　 ∧i. 　｀⌒´-'´　　u; 　ﾉ　ヽ
　　　　　　 |　　　 .＼ヽ　、　 ,　　　　／　　　 |
　　　　　　　　 .ヽ　　　 ',.　　ー　　一　 ./ 　　 /
　　　　　　　　　　',　　　.',　　　　　　　　./　　　/
　　　　　　　　　　 .',　　　',　　　　　　　/　　　/
　　　　　　　　　　 /ヽ、　＼　　　　／　　　/
　　　　　　　　　 /　　|　　　ヽ―‐/　　　 ./ ＼
　　　　　　　　 ./　　 .l　　　丿　ゝ　　　(　　ヽ
　　　　　　　　 /　　　/　　／　　　　＼　 ',　　　 ',
　　　　　　　 /　　　/-‐''´　　　　　　　｀''‐|　　　　',
　　　　　　　./　　 __|　　　　　　　　　　　 . /　　　 .',
　　　　　　　|　　　　｀ヽ、　　　　　　　　.／￣　　 .|
　　　　　　　|　　　　　　ヽ　　　　　　　/　　　　　　 /
　　　　　　　｀"''-,,＿_ ,,,,丿　　　　　　ゝ、＿＿,,-''

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

>>1
匿名クラスは嫌。

まぁ俺の用途では関数内関数で十分なことが多い。
なのでけっこう>>2には同意。

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

>>8
最後の行に同意してくれてありがとう

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

おもてたんとちゃうこのスレ

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

クロージャーってただのメソッド一つのクラスだろ

**デフォルトの名無しさん** · 2014/11/09(日) 01:25:23.88

まじすか

**デフォルトの名無しさん** · 2014/11/09(日) 02:04:06.76

という見方、扱い方もできるねって話だろ

**デフォルトの名無しさん** · 2014/11/09(日) 05:57:17.96

ActionListenerなんて、実装当時にクロージャがあったら存在してたかどうか怪しいクラスだよね

**デフォルトの名無しさん** · 2014/11/09(日) 07:54:16.27

lispの方言かとおもった

**デフォルトの名無しさん** · 2014/11/09(日) 09:19:55.73

>>2
関数型言語では、基本的に変数を書き換えるのは例外的な操作だから
不用意に変数を書き換えることは殆ど無いし、
それなら環境が見えてる事のメリットの方が大きい

**デフォルトの名無しさん** · 2014/11/09(日) 10:23:47.55

>>11
複数にできるよ

**デフォルトの名無しさん** · 2014/11/09(日) 16:16:30.86

関数内で関数が定義できる事とクロージャと何の関係があるんだ？
比較できるものじゃないでしょ

**デフォルトの名無しさん** · 2014/11/09(日) 16:48:40.28

まあ、クロージャは関数内関数の用途をも内包することは多いんじゃね？

**デフォルトの名無しさん** · 2014/11/09(日) 17:24:14.45

>>16
それはあまり使われていない関数型言語限定の話ですね。

**デフォルトの名無しさん** · 2014/11/09(日) 17:32:09.95

>>1は関数型言語の話をしてるんじゃないのか。

> 関数型言語に必ずくっついてるこれ

**デフォルトの名無しさん** · 2014/11/09(日) 17:38:41.70

オレオレ言語仕様を考えてるんだけどさ今どの言語を見てもlambdaだらけじゃない
RAII出来る言語だとクロージャに環境掴まれるだけでリソースリークしそうなわけよ
ならイランでしょ？というわけでたてた

**デフォルトの名無しさん** · 2014/11/09(日) 18:18:41.40

クロージャだからって外の環境全部掴む必要無いんじゃね
クロージャが使用してない変数については各スコープのタイミングで解放すれば十分じゃないの

**デフォルトの名無しさん** · 2014/11/09(日) 18:20:47.86

evalが使える言語では、使用していないかどうか
実行するまでわからないのでそれは無理。

**デフォルトの名無しさん** · 2014/11/09(日) 18:24:28.78

>>20,21
関数型言語ではなく関数型プログラミングの話だと考えれば、
すでに多くの言語でクロージャという概念は幅広く普及していると言えるのではないかと
たとえば C#、Java8、C++11、JavaScript、Ruby 等々

もちろん Python のように、クロージャが存在しない手続き型言語も広く使われているけどね
また、C++ や Java でも古い規格だとクロージャは存在していなかった

**デフォルトの名無しさん** · 2014/11/09(日) 18:40:07.36

Pythonの関数は外の環境掴んでるからクロージャ
嘘は良くない

**デフォルトの名無しさん** · 2014/11/09(日) 18:40:57.06

>>24
クロージャじゃなくてevalを禁止すれば良いんじゃね？

**デフォルトの名無しさん** · 2014/11/09(日) 18:55:58.44

>>26
>>25 で挙げたクロージャを備えた言語は、どれも外の環境を掴んで
ローカル変数に代入できる(=局所環境内の識別子に束縛できる)

それに対して，Python のラムダ式では外の環境を掴めないからクロージャではない
つまり Python は、クロージャを持たない手続き型言語

(ラムダ式ではなく)関数で外の環境を掴めるのは当たり前の話であり、嘘は良くない

**デフォルトの名無しさん** · 2014/11/09(日) 18:59:22.34

>>28 を訂正、ラムダ式(匿名関数)の話であるのを書き忘れていた

X：>25 で挙げたクロージャを備えた言語は、どれも外の環境を掴んで
O：>25 で挙げたクロージャを備えた言語は、どれもラムダ式の中で外の環境を掴んで

**デフォルトの名無しさん** · 2014/11/09(日) 19:03:23.62

>>28
ラムダ式では代入は出来ないけど外の環境は掴んでるからクロージャ
嘘は良くない

**デフォルトの名無しさん** · 2014/11/09(日) 19:08:15.30

不毛だからケンカする前に用語を定義しろよ
オレオレ定義じゃないんだったら引用も必要

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%BC%E3%82%B8%E3%83%A3

> クロージャ（クロージャー、英: closure）、関数閉包はプログラミング言語における関数オブジェクトの一種。
> いくつかの言語ではラムダ式や無名関数で実現している。引数以外の変数を実行時の環境ではなく、
> 自身が定義された環境（静的スコープ）において解決することを特徴とする。

**デフォルトの名無しさん** · 2014/11/09(日) 19:13:25.68

> (ラムダ式ではなく)関数で外の環境を掴めるのは当たり前の話であり、嘘は良くない

とりあえずelispにケンカ売ってるのだけは分かった

**デフォルトの名無しさん** · 2014/11/09(日) 19:19:20.49

pythonのlambdaって外の環境見えないの？

**デフォルトの名無しさん** · 2014/11/09(日) 19:22:02.17

見えるよ

**デフォルトの名無しさん** · 2014/11/09(日) 19:25:16.21

そうだよね...

**デフォルトの名無しさん** · 2014/11/09(日) 19:39:55.45

>>30
C#、Java8、C++11、JavaScript、Ruby 等々の関数型プログラミングが可能な言語では、
どれも「ラムダ式の中であっても外の環境を参照し、それを局所環境に保存」できる

それに対して、Python だと「ラムダ式の中では外の環境を参照する」ことしかできない
つまり、手続き型言語の Python は関数型プログラミングには不向きである、と言える

>>31
>> 引数以外の変数を実行時の環境ではなく、
>> 自身が定義された環境（静的スコープ）において解決することを特徴とする。

クロージャを備えた言語ではクロージャ自身が局所環境を持つということだね(>>4 も参照)
だから、関数内でもラムダ式内であっても局所環境で変数を解決できる

それに対して(クロージャを備えず、代わりに)関数という実行環境しか持たない Python では、
関数内では変数を解決できてもラムダ式内で変数を解決できない
つまり、Python はクロージャを持たない手続き型言語

**デフォルトの名無しさん** · 2014/11/09(日) 19:44:13.19

pythonのlambdaって単に単純な関数定義のシンタックスシュガーなんじゃないの？
lambdaなんて名前が付いてるからアレだけど。

**デフォルトの名無しさん** · 2014/11/09(日) 19:44:17.88

>>33
もちろん見えるよ

ただしクロージャが無いから、その(ラムダ式の中から)見えた値を局所環境に保存できない
関数の中ならば(関数が持つ)局所環境に保存できるんだけどね....

**デフォルトの名無しさん** · 2014/11/09(日) 19:47:57.23

>>36
・「変数を解決する」という用語が未定義
・「ラムダ式のみクロージャと認める」というのは>>31とは異なる定義だが、そのような定義をしている文献が引用されてない

やり直し

**デフォルトの名無しさん** · 2014/11/09(日) 19:48:24.99

>>38
ラムダ式を評価した結果も関数定義を評価した結果も同じfunctionだよ。

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

>>40 たしかに

import inspect

def func(x):
return lambda n: x * n

func(5)(4) #=> 20 (Clojure)
inspect.isfunction(func) #=> True
inspect.isfunction(func(1)) #=> True

**デフォルトの名無しさん** · 2014/11/09(日) 20:10:51.52

>>39
>・「変数を解決する」という用語が未定義

失礼、言語処理系や言語意味論を知らない人には難しい表現だった

「変数を解決する」とは、変数に束縛された値を求めることを意味する
単純な実装では、変数と値の対(ペア)の集合である環境から、変数をキーに値を探索することで実現できる

>・「ラムダ式のみクロージャと認める」というのは>>31とは異なる定義だが、そのような定義をしている文献が引用されてない

「ラムダ式のみクロージャと認める」とは言っていないよ
C#、Java8、C++11、JavaScript、Ruby 等々の一般的な言語では関数でもラムダ式でも局所環境を持てる
これは「クロージャ自身が局所環境を持つ(>>4)」というクロージャ定義からすれば、自然な結果である
それに対して、ラムダ式では局所環境を持てない Python にはクロージャの概念が欠落しているんじゃないのか？
と指摘しているだけ

あるいは処理系への実装を失敗した？、あるいは言語設計上の欠陥を見落とした？という指摘と言い換えてもいい
Python の言語設計者達はクロージャの概念を知っているつもりだったのかもしれないけどね......

**デフォルトの名無しさん** · 2014/11/09(日) 20:14:38.63

>>42
お前こそ良く分かってなくて用語使ってるだろ
そういうのは変数の再束縛っていうんだよ
そんでお前は変数の再束縛と局所環境が持てない事を混同してる

**デフォルトの名無しさん** · 2014/11/09(日) 20:19:48.73

pythonでは関数＝クロージャなんじゃないの？
ラムダ式は関数定義の略記方だよ。

**デフォルトの名無しさん** · 2014/11/09(日) 20:27:21.21

変数に束縛された値を求めることは評価するっていうんだと思う。
再束縛は別の値を束縛すること。

**デフォルトの名無しさん** · 2014/11/09(日) 20:32:25.05

Lispっぽくクロージャ書けるよ

f = (lambda x:
(lambda y=2*x:
(lambda z=x*y:
(lambda w: w * (y + z))))()())
g = f(2)
g(3) #=> 36

**デフォルトの名無しさん** · 2014/11/09(日) 20:34:00.52

>>43
言葉を「変数の再束縛」へ言い換えただけでは、結論は同じだよ

C#、Java8、C++11、JavaScript、Ruby 等々の一般的な言語では関数やラムダ式はクロージャを元に
設計されているから、外の環境を参照した値を「局所変数に再束縛」できる
それが当たり前で、自然な関数型プログラミングができる

それに対して(クロージャを元にしていない)手続き型言語の Python では、
ラムダ式の中だと「局所変数に再束縛」できない
従って、手続き型言語の Python は関数型プログラミングには不向きである

**デフォルトの名無しさん** · 2014/11/09(日) 20:34:54.87

>>45
評価はPythonのラムダの中でも出来るよな？

**デフォルトの名無しさん** · 2014/11/09(日) 20:37:14.94

>>47
よし、あとはラムダの中で変数の再束縛ができないと
その言語にクロージャが無い事になるという文献を引っ張ってこい

**デフォルトの名無しさん** · 2014/11/09(日) 20:40:33.21

>>47
Pythonのラムダ式では局所変数に再束縛できない、は間違い(>>46)
嘘は良くない

**デフォルトの名無しさん** · 2014/11/09(日) 20:49:43.56

>>44
そうだよ

**デフォルトの名無しさん** · 2014/11/09(日) 21:05:06.25

>>47
クロージャを備えた言語であれば、ラムダ式を入れ子にした複雑なコードを書かなくても、
単純明瞭で可読性の高いコードが書ける

f = function(x) {
　　y = 2 * x;
　　z = x * y;

　　return function(w) { return w * (y + z) }
}
g = f(2);
print(g(3));

これがクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の普通の言語と
関数型プログラミングに不向きな手続き型言語 Python との違い

**デフォルトの名無しさん** · 2014/11/09(日) 21:08:04.55

ラムダ式の入れ子は分かりにくいから
関数型プログラミングに向いてない

関数型とは一体…

**デフォルトの名無しさん** · 2014/11/09(日) 21:09:53.89

そもそも関数型プログラミングって堂々と代入してるようじゃダメなのでは

**デフォルトの名無しさん** · 2014/11/09(日) 21:12:20.49

どれだけ間違いを指摘しても
Pythonにクロージャが無いって意見を上書きできない

これが参照透過性です

**デフォルトの名無しさん** · 2014/11/09(日) 21:14:02.40

（>>52 の続き）
もちろん関数型言語であれば、>>52 の JavaScript より更に簡潔になるのは当たり前の話
以下は Standard ML

val f = fn x => let
　　　　val y = 2 * x
　　　　val z = x * y
　　in
　　　　fn w => w * (y + z)
　　end
val g = f 2

g 3

**デフォルトの名無しさん** · 2014/11/09(日) 21:18:46.76

>>53
>ラムダ式の入れ子は分かりにくいから
>関数型プログラミングに向いてない

添削しよう：

　ラムダ式の入れ子は分かりにくいから、
　ラムダ式の入れ子や関数内関数を多用しなければならない手続き型言語の Python は
　関数型プログラミングに向いてない

それに対して、クロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の普通の言語では、
クロージャ自身が持つ局所環境内の変数に代入(=束縛)できるから、
関数型プログラミングに向いている

**デフォルトの名無しさん** · 2014/11/09(日) 21:25:01.25

>>50
Python ができるのは、引数に再束縛することだけ
局所変数(>>52,56 の y と z)には代入できない

Python でも「ラムダ式では局所変数に再束縛できる」と主張したいのなら、
ラムダ式の入れ子や関数内関数を使わずに、可読性の悪い >>47 のコードを書き直しなさい
もし Python に真のクロージャが存在するのなら、簡単な仕事のはずだ

できるよね？　できないのなら、嘘つきは君のほうだよ

**デフォルトの名無しさん** · 2014/11/09(日) 21:31:21.14

変数に再束縛できないから、変数に代入できないに意見が変わったね
やっと>>30に追いついたね

**デフォルトの名無しさん** · 2014/11/09(日) 21:36:16.07

>>46の変数は外から見えないという意味で
紛れもなく局所変数

**デフォルトの名無しさん** · 2014/11/09(日) 21:41:46.54

Java 8にクロージャなんかあったっけ？
ただのラムダだったような

**デフォルトの名無しさん** · 2014/11/09(日) 21:44:14.34

>>59,60
ぐだぐだ屁理屈を言うより、さっさと >>47 のコードを書き直した方がいいんじゃね？

それとも Python コミュニティでは >>47 みたいな
　　ラムダ式を入れ子にしたカッコだらけ
のコードが可読性のある美しいコードなのかなあ
自分には、>>52,56 のほうが可読性の高いコードだと思うけどね

**デフォルトの名無しさん** · 2014/11/09(日) 21:45:18.38

普通は関数定義するよ
当たり前じゃん

**デフォルトの名無しさん** · 2014/11/09(日) 21:49:19.33

ところで関数はクロージャじゃないって
どこの文化なの？
聞いたことない

**デフォルトの名無しさん** · 2014/11/09(日) 21:50:58.85

>>61
>>4 で書いたように、クロージャは抽象的な概念だよ
言語の意味論を定義したり言語処理系を設計する時に用いられる抽象構文で現れる
この抽象構文上のクロージャは、具象構文では一般にラムダ式とか無名関数(匿名関数)と呼ばれる

たとえば Java 8 のラムダ式がそうだし、JavaScript の具象構文では function() { .... } と書き、
Standard ML では fn <id> => <expr> という具象構文で表現される

**デフォルトの名無しさん** · 2014/11/09(日) 21:55:24.38

言語的にはJavaのラムダは
ただのメソッド一つのクラスだよ

**デフォルトの名無しさん** · 2014/11/09(日) 21:58:19.30

>>64
自分も聞いたことないね
そんなこと言ってるお馬鹿さんはいるのかな？

まあ正確に言うと、クロージャを識別子に束縛したものが関数だから、
束縛されていない無名関数(=ラムダ式)と区別することが必要な文脈もあるけどね(>>4)

**デフォルトの名無しさん** · 2014/11/09(日) 22:04:34.10

>>67
じゃあPythonにクロージャはあるの？
Yes/Noで答えて

**デフォルトの名無しさん** · 2014/11/09(日) 22:05:03.57

Java 8のクロージャは「effectively finalに限りキャプチャ可能」
というなんちゃってな局所環境だけどな
effectively finalの導入でかろうじて使い物になるかも知れないレベル

**デフォルトの名無しさん** · 2014/11/09(日) 22:10:31.90

>>63
普通は局所変数に代入するだろ、>>52 みたいに
　　y = 2 * x
　　z = x * y

それとも、Python ではこんな単純な代入文も書かずに(書けずに？)、
わざわざ関数定義するのが当たり前なのかなあ？

**デフォルトの名無しさん** · 2014/11/09(日) 22:13:13.99

>>38
…Haskellにはクロージャが無いと？

**デフォルトの名無しさん** · 2014/11/09(日) 22:21:17.10

>>68
Yes/No であれば No だ

繰り返しになるけど、
真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々におけるクロージャの定義と、
手続き型言語の Python におけるクロージャの定義は異なっている
Python では識別子に束縛したクロージャ、いわゆる関数しか存在できず、
局所環境を伴うラムダ式を表現できない

このため、>>47 のような
　　ラムダ式が入れ子になったカッコだらけ
の汚いコードしか書けない
結果として、Python は関数型プログラミングには不向きである

**デフォルトの名無しさん** · 2014/11/09(日) 22:21:52.15

>>70
だから普通はこう書くよ
あれ？一番簡潔になった？

def f(x):
y = 2 * x
z = x * y
return lambda w: w * (y + z)
g = f(2)
g(3)

**デフォルトの名無しさん** · 2014/11/09(日) 22:25:17.72

>>67
そっちが言う馬鹿(>>72)がいたよ

まさかの同一ID⁉︎

**デフォルトの名無しさん** · 2014/11/09(日) 22:28:55.78

>クロージャを識別子に束縛したものが関数だから

C#やECMAScriptの匿名関数は関数ではないと。
珍妙な新説ですなふむふむ

**デフォルトの名無しさん** · 2014/11/09(日) 22:31:31.78

>>71
>>38における「値を局所環境に保存」とは、識別子と値の対(ペア)を局所環境に追加すること(>>42 も参照)

ここで、追加の時に既に同じ名前の識別子が存在していた場合、手続き型言語では値を破壊的に更新するけど、
関数型言語では新たに局所環境が生成される(=破壊的に更新しない)点が異なる
ただし、この追加時の振る舞いの差異は、クロージャが存在する/しないとは無関係、ごっちゃにするのは間違い

**デフォルトの名無しさん** · 2014/11/09(日) 22:45:45.31

>>73
たとえば JavaScript なら、ラムダ式だけ(>>52)と関数定義との併用、
それらのどちらでも簡潔なコードが書けるよ

function f(x) {
　　y = 2 * x
　　z = x * y
　　return function(w) { return w * (y + z) }
}
g = f(2)
g(3)

結局、Python では「ラムダ式を放棄して」関数定義しなければ簡潔なコードを書けない、
ということが実証されてしまったようだね

つまり、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々のふつうの言語では、
ラムダ式だけでも関数定義との併用でも、ケースバイケースで選択して簡潔で可読性のあるコードを「書ける」けど、
手続き型言語の Python だとラムダ式だけでは「入れ子になったカッコだらけ」の汚いコード(>>47)しか書けないから、
常に関数定義で「書かなければならない」という違いがある

**デフォルトの名無しさん** · 2014/11/09(日) 22:46:49.16

>>76
お前のオレオレ定義なんて興味ねーんだよ
まずはその珍説が書いてある文献を引用しろ

**デフォルトの名無しさん** · 2014/11/09(日) 22:49:23.73

>>77
>>44

**デフォルトの名無しさん** · 2014/11/09(日) 22:51:44.34

>>77
関数定義で可読性も簡潔さも失わないから、関数で書ければ良いよ

で、なぜ関数定義でクロージャが作れる
Pythonにクロージャがない事になるの？
>>68にNoと答えて、>>64も否定したよね？

**デフォルトの名無しさん** · 2014/11/09(日) 22:54:09.40

>>79
そいつ、関数を定義する特定のシンタックスシュガーに制限があることと
その言語自体が持つ機能との区別が付かない馬鹿だから

**デフォルトの名無しさん** · 2014/11/09(日) 22:56:01.93

でもまあ、pythonの文法が変態なのは間違いない。

**デフォルトの名無しさん** · 2014/11/09(日) 22:56:21.23

>>73
ナゼ Python では、以下のような簡潔なコードが構文エラーになるんだろうね？

f = lambda x:
　　y = 2 * x
　　z = x * y
　　return lambda w: w * (y + z)
g = f(2)
g(3)

これじゃあ「Python は関数型プログラミングに向かない」と評価されてもしかたないよね
だって、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々のふつうの言語では、
>>52 みたいなラムダ式だけを使ったコードが何の苦もなく自然に書けるんだから

**デフォルトの名無しさん** · 2014/11/09(日) 22:59:47.88

83はキチガイなの？
>>73は明らかに実行時のy,zを取り込んだ関数オブジェクトを生成してるからクロージャだろ
defと書くかlambdaと書くか文法の些細な決まり事などどうでもいい

**デフォルトの名無しさん** · 2014/11/09(日) 23:01:05.93

>>83
同程度に簡潔に書けるなら、書き方は一つの方が良い
というのがPythonの理想だから

**デフォルトの名無しさん** · 2014/11/09(日) 23:08:28.24

>>80
>で、なぜ関数定義でクロージャが作れる
>Pythonにクロージャがない事になるの？

>>72 で書いたように、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の
ふつうの言語では(関数定義だけではなく)ラムダ式でもクロージャが作られるという違いがあるからだ
対して、Python のラムダ式ではクロージャが作られない（だから、局所変数へ値を代入できない）

もし「Pythonにクロージャがない」という主張が不適切であるのならば、
>>42 の最後で書いたように、
　「Python の言語設計者達は、処理系への実装を失敗した、あるいは言語設計上の欠陥を見落とした」
と言い換えてもいいよ

こんな使い物にならないラムダ式で満足しなければならないとは、最大の被害者は Python プログラマだよね
だって、他のふつうの言語であれば「ふつうに書ける」ことが、Python じゃ「書けない」のだから....(>>83)

**デフォルトの名無しさん** · 2014/11/09(日) 23:13:26.40

ラムダ式の構文が残念だと言いたいなら、最初からそう言えばいいじゃん。

**デフォルトの名無しさん** · 2014/11/09(日) 23:16:00.89

>>84
ラムダ式が引数に値を束縛できるのは、関数型言語を知っていれば常識だよ
そんなことも知らないの？

で、引数以外の局所変数に値を束縛するには、純粋なラムダ式に加えてクロージャが必要になるって話だよ

**デフォルトの名無しさん** · 2014/11/09(日) 23:18:21.66

>ラムダ式が引数に値を束縛できるのは

それ束縛じゃねーだろ
キミはアホなのか？

**デフォルトの名無しさん** · 2014/11/09(日) 23:18:59.88

>>88
>>73のy, zのどこが引数なんだよ
既知外は黙ってろよ

**デフォルトの名無しさん** · 2014/11/09(日) 23:23:03.86

>>46の話ならデフォルト引数で値を入れてるから
普通に関数適用で引数に値を入れてるのとは厳密には違うよ？
どうでも良いけどね

**デフォルトの名無しさん** · 2014/11/09(日) 23:26:01.65

>>86
Pythonにクロージャが無いは嘘ってことね
嘘は良くない

**デフォルトの名無しさん** · 2014/11/09(日) 23:27:54.79

>>90
>>88で書いたのは >>41 のラムダ式だけで書かれた Python コードだ
失礼した

>>73 は関数定義でクロージャが作られているね
ただし、Python だけがラムダ式ではクロージャが作られず、
Python におけるクロージャの定義が他の「普通の言語」と異なっている事実に変わりはない

**デフォルトの名無しさん** · 2014/11/09(日) 23:30:45.91

>>93
お前は無名関数って何がいいの？スレを立てて、そこで思う存分Pythonのlambdaを罵倒するべき
クロージャ云々は言いたい事と噛み合ってない

**デフォルトの名無しさん** · 2014/11/09(日) 23:33:02.09

>>92
Python には真のクロージャが存在しない、という指摘は事実だよ(嘘ではない)

もし「Python にも真のクロージャが存在する」と主張したいのなら、
>>83 のコードが構文エラーとならないように添削しなさい
もし「Python にも真のクロージャが存在する」のなら、たやすい作業のはずだ
真のクロージャを備えた普通の言語では、何の苦も無く >>52 みたいなコードが書けるんだからね

君が嘘つきでなければ、書けるはず

**デフォルトの名無しさん** · 2014/11/09(日) 23:33:22.37

使い勝手で一番使い物にならないのはJavaだろ？
void m() {
　int y = f();
　y = y + 1;
　new Thread(
　　() -> {ここでyを使えないKUSO言語}
　);
}

**デフォルトの名無しさん** · 2014/11/09(日) 23:33:25.09

ID:KOr7L+hP が言ってるのは、

関数の引数にもう少し複雑な処理をインラインで書きたいのに、
defは値返さねえし、lambdaは1行しか書けねえし、
まったく融通がきかねえな！

みたいな字面上の不満であって、関数型プログラミングだのクロージャだの全然関係ない。

**デフォルトの名無しさん** · 2014/11/09(日) 23:36:58.94

>>95
関数は局所環境持ってても「真のクロージャ」じゃないってこと？
Yes/Noで答えて

**デフォルトの名無しさん** · 2014/11/09(日) 23:39:26.26

真のクロージャとかいうオレオレ用語
もちろん引用もなければ定義もない

**デフォルトの名無しさん** · 2014/11/09(日) 23:40:53.08

>>94
クロージャという概念を正しく理解していないと、
Python みたいなラムダ式に欠陥のある言語が設計されてしまうというお話だよ
言い換えると、クロージャという概念を用いると、
なぜ Python のラムダ式が欠陥品なのかを明解に説明できる

このクロージャの利点は、このスレの主旨からは逸脱していないと思うよ

**デフォルトの名無しさん** · 2014/11/09(日) 23:42:02.22

>>100
お前がこのスレで一番クロージャを理解してない件
構文の字面しか見てないし

**デフォルトの名無しさん** · 2014/11/09(日) 23:57:43.62

>>98
No だね

あえていえば「クロージャもどき」とか「なんちゃってクロージャ」だね
真のクロージャであれば無名関数でも間数定義でも作られ、
無名関数であってもクロージャを構成する局所環境を持つことができる
これが、 C#、Java8、C++11、JavaScript、Ruby 等々の
「ふつうの言語」における「ふつうのクロージャ」だ

おそらくクロージャを正しく理解していなかったんだろね、Python 言語設計者達は....

**デフォルトの名無しさん** · 2014/11/09(日) 23:59:39.38

話をまとめよう

世間一般のクロージャの要件：
　局所環境を持つ(変数を束縛できる)
　関数をインラインで書ける

キチガイのクロージャの要件：
　クソージャの中にクソージャが書ける
　若しくは
　言語設計上の欠陥を見落としたことを認める(>>86の発言)
　のいずれか

**デフォルトの名無しさん** · 2014/11/10(月) 00:08:24.74

>>103
添削してあげよう

--
話をまとめよう

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

Python に固有なクロージャの要件：
　関数だけが局所環境を持つ(変数を束縛できる)：>>73
　無名関数では局所環境を持てない(変数を束縛できない)：>>46,83

**デフォルトの名無しさん** · 2014/11/10(月) 00:14:31.96

まあここはscheme最強っていう事にしておきますか。

**デフォルトの名無しさん** · 2014/11/10(月) 00:28:52.73

>>101
> 構文の字面しか見てないし

だとすれば、Martin Fowler氏も「構文の字面しか見てない」ってもとになるんだろな

・Martin Fowler's Bliki in Japanese - クロージャ
　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Closure

Lsip/Smalltalk/Ruby/JavaScript といったプログラミング言語では、
クロージャやブロックを多用したスタイルが好まれる
だから、Python みたいな無名関数で局所環境を持てない言語で同じようにクロージャを
多用するスタイルを試みると、「ラムダ式が入れ子でカッコだらけ(>>46)」な汚いコードや、
いちいち「関数定義しなければならない(>>73)」ケースと頻繁に出会うから、ストレスが溜まる
まあ「Python は手続き型言語」だから仕方ないんだよと自分に言い聞かせて我慢してるけど、
プログラミング言語を自由に選べるなら、真っ先に Python は除外するね、自分なら

もし、これが「構文の字面しか見てない」と思えるのなら、それはそれでもいいんじゃないのかもね.....

**デフォルトの名無しさん** · 2014/11/10(月) 00:37:52.21

Pythonはlambdaの不便さも含めて構文がアレなので大嫌いだけど、
ライブラリが色々そろってて便利だから結局よく使っているのであった。

**デフォルトの名無しさん** · 2014/11/10(月) 00:42:53.31

pythonのlambdaってmapやfilterを追加したときに申し訳程度に付けたって感じ

**デフォルトの名無しさん** · 2014/11/10(月) 02:52:22.03

>>106
その文章を書いた人の考えと、君の解釈には随分とズレがあるようだ

**デフォルトの名無しさん** · 2014/11/10(月) 06:04:53.17

馬鹿には無理

**デフォルトの名無しさん** · 2014/11/10(月) 07:14:42.95

Pythonの不自由さ(関数型のクロージャに近いの)はGuidoの方針じゃないの？
嫌なら、おとなしくジェネレータ使えばいいじゃん。

**デフォルトの名無しさん** · 2014/11/10(月) 08:48:39.72

クロージャは何がいいんだよ！
https://i.imgur.com/fTQTEYN.gif

**デフォルトの名無しさん** · 2014/11/10(月) 09:04:03.39

引数に別名付けたくなる程に中身が長いなら
関数にも名前付けろってのがGuidoの方針なんだろ
文法的に拡張可能なのに、あえてリジェクトしてるくらいだし
http://www.artima.com/weblogs/viewpost.jsp?thread=147358

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

>>106
Martin Fowlerは字面だけを見てないから、ちゃんとPythonにもクロージャがあると思ってるよ

お前が張ったリンク先の「他の言語」を見てみろ

1 · 2014/11/10(月) 11:39:28.98

何がクロージャかよりどこが好きかでクロージャを語れよ！！(ﾄﾞﾝｯ

**デフォルトの名無しさん** · 2014/11/10(月) 20:33:09.35

クロージャとメソッドで f[x] と f(x) を使い分けなきゃダメなRubyが
一番ウンコだと思う

**デフォルトの名無しさん** · 2014/11/10(月) 20:39:42.07

>>116
それはクロージャとメソッドではなく、Procとメソッドだと思う
Rubyのクロージャはブロックのほうの機能と考えたほうが良いんじゃないかな

**デフォルトの名無しさん** · 2014/11/10(月) 21:34:09.37

>>115

俺の財宝か？欲しけりゃくれてやる。
探せ！この世の全てをそこに置いてきた。

**デフォルトの名無しさん** · 2014/11/10(月) 22:47:25.14

文系出身プログラマ「クロージャ？なにそれ？服入れるとこ？？」
ってやつに対してドヤ顔ができる

**デフォルトの名無しさん** · 2014/11/11(火) 06:32:45.68

クロー系の最強魔法です　消費MP60

**118** · 2014/11/11(火) 21:00:28.44

レスお願いします

**デフォルトの名無しさん** · 2014/11/11(火) 22:06:02.40

若い時に買ってでもすることは？

苦労じゃ！くろうじゃ！クロージャ！

**デフォルトの名無しさん** · 2014/11/12(水) 01:25:01.41

クロージャの良さを、クロージャを使うことで劇的に
簡潔になる例を使って説明してください

**デフォルトの名無しさん** · 2014/11/12(水) 07:27:28.43

コールバック関数を別途書かなくて良くなります。
もしコールバック関数の為だけにインスタンス変数を定義していたなら、
それも必要が無くなります。

消費MP 5

**デフォルトの名無しさん** · 2014/11/12(水) 08:10:30.04

コールバック関数地獄のJSのコードは
可読性が悪い上に簡潔でも無いので、失格です

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

オールバックって額からハゲるだろ？

**デフォルトの名無しさん** · 2014/11/12(水) 08:27:11.27

>>125
そんなあなたにClojureScript。
core.asyncのチャネルでスッキリしますよ（Go由来のようだけど）

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

>>127
コールバック自体がダメなんだよ。
例えば、addEventLisnerの引数にコールバックを指定する。
これだけでも可読性悪いだろ。

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

見慣れてるかどうかだと思うけどな

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

>>128
代案も出さずに批判だけするなら、幼稚園児にだってできるよ

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

リスナーI/Fをインプリメントしたオブジェクト渡せばいいのでは

**デフォルトの名無しさん** · 2014/11/12(水) 21:14:25.68

それではそのオブジェクトを定義しなくてはならなくなります。
クロージャはそのようなデリゲートオブジェクトやコールバックパターンからの解放なのです。

消費MP 12

**デフォルトの名無しさん** · 2014/11/12(水) 21:16:45.87

JavaScript（だけに限らないが）
クロージャーが見難いんじゃなくて
非同期の入れ子が見にくいんだろ。
で、それを解決するライブラリが存在する。

結局のところ、そのライブラリ
Promiseとかを使えば解決する問題。

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

結局のところ、コールバックはクロージャのメリットじゃないんですね？
もっと良い方法があるのですから

**デフォルトの名無しさん** · 2014/11/12(水) 21:36:55.56

いや、クロージャ使ってそのスコープで解決しちゃえばコールバック関数要らないって話なんだが。

**デフォルトの名無しさん** · 2014/11/12(水) 21:59:20.14

Haskellのdo記法みたいなのがあれば
クロージャをチェインしていっても読み難くならないという話ですか？

**デフォルトの名無しさん** · 2014/11/12(水) 22:58:17.02

小規模なコールバックだったらインラインで書いた方が見通しが良いだろうし、
複雑なのだったら分けて書いた方が理解しやすいだろうし、
あれが最強他はゴミとか言ってるのが一番ダメなんじゃね？

**デフォルトの名無しさん** · 2014/11/15(土) 12:17:49.98

結局クロージャの利点てコールバックが楽にかけるってだけ？
ならクロージャや匿名オブジェクトじゃなくて匿名メソッドが書ければ充分だな

**デフォルトの名無しさん** · 2014/11/15(土) 12:25:31.04

楽に書けるって事じゃなくて、そのスコープで完結できるって事じゃね？

**デフォルトの名無しさん** · 2014/11/15(土) 12:56:58.32

とりあえずコードで語れば？
大規模開発でメリットが出てくるとかの話じゃないんだし

**デフォルトの名無しさん** · 2014/11/15(土) 14:40:16.71

見た目的にも変数の値の可視性的にもそこのスコープってとこが楽だよね

**デフォルトの名無しさん** · 2014/11/15(土) 14:43:26.00

つまりインラインでクラス定義できるのでも良いわけだよね

**デフォルトの名無しさん** · 2014/11/15(土) 15:14:55.72

>>142
本来そうだけど、
シンタックスはインラインだけど実際はただの内部クラスで、
生成時の環境を一切利用できない言語もあるから何とも言えない。

クロージャの代わりにクラスを用いると何となくそういう実装になる。
ローカル環境の代わりにインスタンス変数を用いる方向にいくから。

FILE *fp = fopen(..);
doHoge( ^(const char*msg){ fputs(msg,fp); });
fclose(fp);

みたいに簡便にクロージャ生成時の外部の変数(の値のコピー)を
保持し使用できるクロージャとは方向性が違う。

ローカルメソッドに至っては環境が一昨渡せない
シングルスレッド前提ならグローバル変数を使えばいいわけだけど

**デフォルトの名無しさん** · 2014/11/15(土) 15:54:48.49

(擬似言語)
fw = new FileWriter();
doHoge( fw.witer );
fw.close();
こんなのをワンラインで書ければ満足なんだろ？匿名メソッドで十分じゃない

**デフォルトの名無しさん** · 2014/11/15(土) 15:58:46.71

>>144
じゃ匿名メソッドで書いてごらんよ

**デフォルトの名無しさん** · 2014/11/15(土) 23:46:47.75

with (fw, new FileWriter()) {
doHoge(fw.witer);
}
こうやって書けるほうがいい

**デフォルトの名無しさん** · 2014/11/16(日) 10:37:06.14

じゃあこれは？

FILE *fp = fopen(..);
doHoge( ^(const char*msg){ fprintf(fp, "Hoge: %s\n", msg); });
fclose(fp);

**デフォルトの名無しさん** · 2014/11/16(日) 11:54:54.13

>>146
もはや匿名メソッドすら要らない派が出てくるしｗｗ

**デフォルトの名無しさん** · 2014/11/18(火) 16:33:41.48

Java8すら使わせてもらえない人が必死なスレにしか見えなくなってきた

**デフォルトの名無しさん** · 2014/11/19(水) 22:27:12.37

>>144,147
それだと doHoge の実行中に例外が発生するとファイルがクローズされない

たとえばクロージャを多用する Ruby のような言語だと、以下のように書く
　File.open(..) do |file|
　　　doHoge do
　　　　　file.puts(msg)
　　　end
　end
Ruby ではクロージャをブロックと呼ぶけど、ブロック実行中に例外が発生しても
ファイルは確実にクローズされるし、ユーザ定義メソッドでも同様な振る舞いを実装できる

>>146
それに対して、クロージャを持たない手続き型言語の Pascal や Python といった言語では、
同じ事をするのに(>>146 のような) with 構文を使わなければ書けない
クロージャは一級市民だから引数で渡したり呼び出すことができるという自由があるけど、
with 構文はあくまで文(statement)だからクロージャと比較すれば表現力は制限される
いわばクロージャという概念を持たない言語の代用品が with 構文である

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

**デフォルトの名無しさん** · 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 と同様に)辞書を使って書く