TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
クラスとかインスタンスってなんのためにあんの？
なあ、再帰関数好きな人いる？ パート3
Xamarin Part6
最も美しいプログラミング言語は？ Part6
[RPA]PC自動化技術総合スレ[効率化] Part.8
Kotlin 5
Git 13
WPF(.NET4.x, .NET Core) GUIプログラミング Part24
初心者の作ったプログラムにありがちなこと
【C++】 DirectX初心者質問ｽﾚ Part41 【C】
クロージャって何がいいの？
- 1 ：2014/11/08 〜 最終レス ：2018/08/23
- 関数型言語に必ずくっついてるこれ
いらんでしょ？匿名クラスで充分でしょ
- 2 ：
- マジレスすると、クロージャーよりも
関数内関数の方がいい。
クロージャーは変数スコープが不必要に広い。
多くの場合、クロージャーの外は見える必要がない。
逆に見えてしまうと不用意に変数を書き換えてしまう。
関数内関数がない言語が多いから
仕方なくクロージャーを使うしかないが、
Java8のラムダの方がまだ安全なコードを書くことが出来る。
（ラムダも外のスコープが参照できる場合があるので完璧ではない）
つまり俺がいいたいのは、クロージャーを使うと苦労するのジャー。
- 3 ：
- ディスクロージャ
- 4 ：
- >>1
関数型言語の操作的意味論において、クロージャとは：
「ラムダ式と局所環境とを組合せた概念」
を指す
このクロージャを具象構文で表したものが一般的な「ラムダ式」であり、
クロージャを識別子に束縛したものが一般的な「関数宣言」である
Standard ML という関数型言語だと、
たとえばラムダ式は fn x => x + 1 であり、関数宣言は val succ = fn x => x + 1 である
ここで、関数宣言には fun succ x = x + 1 と簡潔に書ける構文糖を用いるのが一般的
だから、あらゆる関数型言語ないし関数型プログラミングが可能なあらゆる言語であれば、
クロージャ(という概念)は必要不可欠に存在である、と言える
また Java の「匿名クラス」もクロージャ(という概念)を応用した具象構文の一種である
で、Java 8 で導入された「ラムダ式」もクロージャの具象構文だけど、
匿名クラスよりも簡潔に書ける利点があるから、多くのケースで広く利用されるようになるだろう
両者の間には、局所環境と組み合わせる対象が「匿名クラス」ではクラスという単位であるのに対して、
「ラムダ式」では式という(クラスよりも粒の小さな)単位であるという違いがある
目的に応じて適切に両者を使い分けることが望ましい
- 5 ：
- ／￣￣￣￣￣￣￣￣￣￣￣￣￣＼
∠ ﾉ
丶 |
ﾉ |
| ／￣￣￣￣＼ |
| / ヽ |
| | | |
| | | |
| | | |
/ | | /
ヽ ＼＿／| |＼＿／ ヽﾍ
| ／ ＼ /
￣￣￣￣￣￣ ￣￣￣￣￣￣
パンとか止めるやつ
- 6 ：
- >>5
それ、パンとか止めるやつだろ！
- 7 ：
- ／￣￣＼
／ _ノ ヽ､_ ＼
. | （ ●）（● ） |
,-,-,-,__ | （__人__） │rヽヽヽヽ__ 「クイックロック バッグ クロージャー！！」
r.l .' ' .'.r_l | ｀⌒ ´ . | ´l .|/
.ヽ| | | | | /＿
._,,-ーヽ /-‐ ヽ /‐''",' /. ｀ヽ
/ /｀''‐-',. ヽ ./ rj,.-‐''´｀l ./
＼ | 二ヽ ヽ三 |ー‐'´
｀''‐ヽ ―｀ﾍ j ｀―r'´
｀T ´ j. ./ j
ヽ .ヽ、 ＿＿＿ / ,'
| .／(＞)＾ ヽ＼ i
| .／ (＿ （＜） ＼ .i
／ .! ./ /rｪヾ__）⌒::: ヾ.＼
/ ∧i. ｀⌒´-'´ u; ﾉ ヽ
| .＼ヽ 、 , ／ |
.ヽ ',. ー 一 ./ /
', .', ./ /
.', ', / /
/ヽ、 ＼ ／ /
/ | ヽ―‐/ ./ ＼
./ .l 丿 ゝ ( ヽ
/ / ／ ＼ ', ',
/ /-‐''´ ｀''‐| ',
./ __| . / .',
| ｀ヽ、 .／￣ .|
| ヽ / /
｀"''-,,＿_ ,,,,丿 ゝ、＿＿,,-''
- 8 ：
- >>1
匿名クラスは嫌。
まぁ俺の用途では関数内関数で十分なことが多い。
なのでけっこう>>2には同意。
- 9 ：
- >>8
最後の行に同意してくれてありがとう
- 10 ：
- おもてたんとちゃうこのスレ
- 11 ：
- クロージャーってただのメソッド一つのクラスだろ
- 12 ：
- まじすか
- 13 ：
- という見方、扱い方もできるねって話だろ
- 14 ：
- A{B{C}} というスコープがあるとき、一般的には、
C→Bのように、内から外はアクセスできるが、
A→Bのように、外から内はアクセスできない
ここで、Aからクロージャで、Bの内部関数Cを返すと、
Cは自分の外部環境Bを保持しており、
CからBをアクセスできるので、その結果、
AからBの環境にもアクセスできる
- 15 ：
- ActionListenerなんて、実装当時にクロージャがあったら存在してたかどうか怪しいクラスだよね
- 16 ：
- lispの方言かとおもった
- 17 ：
- >>2
関数型言語では、基本的に変数を書き換えるのは例外的な操作だから
不用意に変数を書き換えることは殆ど無いし、
それなら環境が見えてる事のメリットの方が大きい
- 18 ：
- >>11
複数にできるよ
- 19 ：
- 関数内で関数が定義できる事とクロージャと何の関係があるんだ？
比較できるものじゃないでしょ
- 20 ：
- まあ、クロージャは関数内関数の用途をも内包することは多いんじゃね？
- 21 ：
- >>17
それはあまり使われていない関数型言語限定の話ですね。
- 22 ：
- >>1は関数型言語の話をしてるんじゃないのか。
> 関数型言語に必ずくっついてるこれ
- 23 ：
- オレオレ言語仕様を考えてるんだけどさ今どの言語を見てもlambdaだらけじゃない
RAII出来る言語だとクロージャに環境掴まれるだけでリソースリークしそうなわけよ
ならイランでしょ？というわけでたてた
- 24 ：
- クロージャだからって外の環境全部掴む必要無いんじゃね
クロージャが使用してない変数については各スコープのタイミングで解放すれば十分じゃないの
- 25 ：
- evalが使える言語では、使用していないかどうか
実行するまでわからないのでそれは無理。
- 26 ：
- >>21,21
関数型言語ではなく関数型プログラミングの話だと考えれば、
すでに多くの言語でクロージャという概念は幅広く普及していると言えるのではないかと
たとえば C#、Java8、C++11、JavaScript、Ruby 等々
もちろん Python のように、クロージャが存在しない手続き型言語も広く使われているけどね
また、C++ や Java でも古い規格だとクロージャは存在していなかった
- 27 ：
- Pythonの関数は外の環境掴んでるからクロージャ
嘘は良くない
- 28 ：
- >>25
クロージャじゃなくてevalを禁止すれば良いんじゃね？
- 29 ：
- >>27
>>26 で挙げたクロージャを備えた言語は、どれも外の環境を掴んで
ローカル変数に代入できる(=局所環境内の識別子に束縛できる)
それに対して，Python のラムダ式では外の環境を掴めないからクロージャではない
つまり Python は、クロージャを持たない手続き型言語
(ラムダ式ではなく)関数で外の環境を掴めるのは当たり前の話であり、嘘は良くない
- 30 ：
- >>29 を訂正、ラムダ式(匿名関数)の話であるのを書き忘れていた
X：>26 で挙げたクロージャを備えた言語は、どれも外の環境を掴んで
O：>26 で挙げたクロージャを備えた言語は、どれもラムダ式の中で外の環境を掴んで
- 31 ：
- >>29
ラムダ式では代入は出来ないけど外の環境は掴んでるからクロージャ
嘘は良くない
- 32 ：
- 不毛だからケンカする前に用語を定義しろよ
オレオレ定義じゃないんだったら引用も必要
http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%BC%E3%82%B8%E3%83%A3
> クロージャ（クロージャー、英: closure）、関数閉包はプログラミング言語における関数オブジェクトの一種。
> いくつかの言語ではラムダ式や無名関数で実現している。引数以外の変数を実行時の環境ではなく、
> 自身が定義された環境（静的スコープ）において解決することを特徴とする。
- 33 ：
- > (ラムダ式ではなく)関数で外の環境を掴めるのは当たり前の話であり、嘘は良くない
とりあえずelispにケンカ売ってるのだけは分かった
- 34 ：
- pythonのlambdaって外の環境見えないの？
- 35 ：
- 見えるよ
- 36 ：
- そうだよね...
- 37 ：
- >>31
C#、Java8、C++11、JavaScript、Ruby 等々の関数型プログラミングが可能な言語では、
どれも「ラムダ式の中であっても外の環境を参照し、それを局所環境に保存」できる
それに対して、Python だと「ラムダ式の中では外の環境を参照する」ことしかできない
つまり、手続き型言語の Python は関数型プログラミングには不向きである、と言える
>>32
>> 引数以外の変数を実行時の環境ではなく、
>> 自身が定義された環境（静的スコープ）において解決することを特徴とする。
クロージャを備えた言語ではクロージャ自身が局所環境を持つということだね(>>4 も参照)
だから、関数内でもラムダ式内であっても局所環境で変数を解決できる
それに対して(クロージャを備えず、代わりに)関数という実行環境しか持たない Python では、
関数内では変数を解決できてもラムダ式内で変数を解決できない
つまり、Python はクロージャを持たない手続き型言語
- 38 ：
- pythonのlambdaって単に単純な関数定義のシンタックスシュガーなんじゃないの？
lambdaなんて名前が付いてるからアレだけど。
- 39 ：
- >>34
もちろん見えるよ
ただしクロージャが無いから、その(ラムダ式の中から)見えた値を局所環境に保存できない
関数の中ならば(関数が持つ)局所環境に保存できるんだけどね....
- 40 ：
- >>37
・「変数を解決する」という用語が未定義
・「ラムダ式のみクロージャと認める」というのは>>32とは異なる定義だが、そのような定義をしている文献が引用されてない
やり直し
- 41 ：
- >>39
ラムダ式を評価した結果も関数定義を評価した結果も同じfunctionだよ。
- 42 ：
- >>41 たしかに
import inspect
def func(x):
return lambda n: x * n
func(5)(4) #=> 20 (Clojure)
inspect.isfunction(func) #=> True
inspect.isfunction(func(1)) #=> True
- 43 ：
- >>40
>・「変数を解決する」という用語が未定義
失礼、言語処理系や言語意味論を知らない人には難しい表現だった
「変数を解決する」とは、変数に束縛された値を求めることを意味する
単純な実装では、変数と値の対(ペア)の集合である環境から、変数をキーに値を探索することで実現できる
>・「ラムダ式のみクロージャと認める」というのは>>32とは異なる定義だが、そのような定義をしている文献が引用されてない
「ラムダ式のみクロージャと認める」とは言っていないよ
C#、Java8、C++11、JavaScript、Ruby 等々の一般的な言語では関数でもラムダ式でも局所環境を持てる
これは「クロージャ自身が局所環境を持つ(>>4)」というクロージャ定義からすれば、自然な結果である
それに対して、ラムダ式では局所環境を持てない Python にはクロージャの概念が欠落しているんじゃないのか？
と指摘しているだけ
あるいは処理系への実装を失敗した？、あるいは言語設計上の欠陥を見落とした？という指摘と言い換えてもいい
Python の言語設計者達はクロージャの概念を知っているつもりだったのかもしれないけどね......
- 44 ：
- >>43
お前こそ良く分かってなくて用語使ってるだろ
そういうのは変数の再束縛っていうんだよ
そんでお前は変数の再束縛と局所環境が持てない事を混同してる
- 45 ：
- pythonでは関数＝クロージャなんじゃないの？
ラムダ式は関数定義の略記方だよ。
- 46 ：
- 変数に束縛された値を求めることは評価するっていうんだと思う。
再束縛は別の値を束縛すること。
- 47 ：
- Lispっぽくクロージャ書けるよ
f = (lambda x:
(lambda y=2*x:
(lambda z=x*y:
(lambda w: w * (y + z))))()())
g = f(2)
g(3) #=> 36
- 48 ：
- >>44
言葉を「変数の再束縛」へ言い換えただけでは、結論は同じだよ
C#、Java8、C++11、JavaScript、Ruby 等々の一般的な言語では関数やラムダ式はクロージャを元に
設計されているから、外の環境を参照した値を「局所変数に再束縛」できる
それが当たり前で、自然な関数型プログラミングができる
それに対して(クロージャを元にしていない)手続き型言語の Python では、
ラムダ式の中だと「局所変数に再束縛」できない
従って、手続き型言語の Python は関数型プログラミングには不向きである
- 49 ：
- >>46
評価はPythonのラムダの中でも出来るよな？
- 50 ：
- >>48
よし、あとはラムダの中で変数の再束縛ができないと
その言語にクロージャが無い事になるという文献を引っ張ってこい
- 51 ：
- >>48
Pythonのラムダ式では局所変数に再束縛できない、は間違い(>>47)
嘘は良くない
- 52 ：
- >>45
そうだよ
- 53 ：
- >>48
クロージャを備えた言語であれば、ラムダ式を入れ子にした複雑なコードを書かなくても、
単純明瞭で可読性の高いコードが書ける
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 との違い
- 54 ：
- ラムダ式の入れ子は分かりにくいから
関数型プログラミングに向いてない
関数型とは一体…
- 55 ：
- そもそも関数型プログラミングって堂々と代入してるようじゃダメなのでは
- 56 ：
- どれだけ間違いを指摘しても
Pythonにクロージャが無いって意見を上書きできない
これが参照透過性です
- 57 ：
- （>>53 の続き）
もちろん関数型言語であれば、>>53 の 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
- 58 ：
- >>54
>ラムダ式の入れ子は分かりにくいから
>関数型プログラミングに向いてない
添削しよう：
ラムダ式の入れ子は分かりにくいから、
ラムダ式の入れ子や関数内関数を多用しなければならない手続き型言語の Python は
関数型プログラミングに向いてない
それに対して、クロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の普通の言語では、
クロージャ自身が持つ局所環境内の変数に代入(=束縛)できるから、
関数型プログラミングに向いている
- 59 ：
- >>51
Python ができるのは、引数に再束縛することだけ
局所変数(>>53,56 の y と z)には代入できない
Python でも「ラムダ式では局所変数に再束縛できる」と主張したいのなら、
ラムダ式の入れ子や関数内関数を使わずに、可読性の悪い >>48 のコードを書き直しなさい
もし Python に真のクロージャが存在するのなら、簡単な仕事のはずだ
できるよね？ できないのなら、嘘つきは君のほうだよ
- 60 ：
- 変数に再束縛できないから、変数に代入できないに意見が変わったね
やっと>>31に追いついたね
- 61 ：
- >>47の変数は外から見えないという意味で
紛れもなく局所変数
- 62 ：
- Java 8にクロージャなんかあったっけ？
ただのラムダだったような
- 63 ：
- >>60,60
ぐだぐだ屁理屈を言うより、さっさと >>48 のコードを書き直した方がいいんじゃね？
それとも Python コミュニティでは >>48 みたいな
ラムダ式を入れ子にしたカッコだらけ
のコードが可読性のある美しいコードなのかなあ
自分には、>>53,56 のほうが可読性の高いコードだと思うけどね
- 64 ：
- 普通は関数定義するよ
当たり前じゃん
- 65 ：
- ところで関数はクロージャじゃないって
どこの文化なの？
聞いたことない
- 66 ：
- >>62
>>4 で書いたように、クロージャは抽象的な概念だよ
言語の意味論を定義したり言語処理系を設計する時に用いられる抽象構文で現れる
この抽象構文上のクロージャは、具象構文では一般にラムダ式とか無名関数(匿名関数)と呼ばれる
たとえば Java 8 のラムダ式がそうだし、JavaScript の具象構文では function() { .... } と書き、
Standard ML では fn <id> => <expr> という具象構文で表現される
- 67 ：
- 言語的にはJavaのラムダは
ただのメソッド一つのクラスだよ
- 68 ：
- >>65
自分も聞いたことないね
そんなこと言ってるお馬鹿さんはいるのかな？
まあ正確に言うと、クロージャを識別子に束縛したものが関数だから、
束縛されていない無名関数(=ラムダ式)と区別することが必要な文脈もあるけどね(>>4)
- 69 ：
- >>68
じゃあPythonにクロージャはあるの？
Yes/Noで答えて
- 70 ：
- Java 8のクロージャは「effectively finalに限りキャプチャ可能」
というなんちゃってな局所環境だけどな
effectively finalの導入でかろうじて使い物になるかも知れないレベル
- 71 ：
- >>64
普通は局所変数に代入するだろ、>>53 みたいに
y = 2 * x
z = x * y
それとも、Python ではこんな単純な代入文も書かずに(書けずに？)、
わざわざ関数定義するのが当たり前なのかなあ？
- 72 ：
- >>39
…Haskellにはクロージャが無いと？
- 73 ：
- >>69
Yes/No であれば No だ
繰り返しになるけど、
真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々におけるクロージャの定義と、
手続き型言語の Python におけるクロージャの定義は異なっている
Python では識別子に束縛したクロージャ、いわゆる関数しか存在できず、
局所環境を伴うラムダ式を表現できない
このため、>>48 のような
ラムダ式が入れ子になったカッコだらけ
の汚いコードしか書けない
結果として、Python は関数型プログラミングには不向きである
- 74 ：
- >>71
だから普通はこう書くよ
あれ？一番簡潔になった？
def f(x):
y = 2 * x
z = x * y
return lambda w: w * (y + z)
g = f(2)
g(3)
- 75 ：
- >>68
そっちが言う馬鹿(>>73)がいたよ
まさかの同一ID⁉︎
- 76 ：
- >クロージャを識別子に束縛したものが関数だから
C#やECMAScriptの匿名関数は関数ではないと。
珍妙な新説ですなふむふむ
- 77 ：
- >>72
>>39における「値を局所環境に保存」とは、識別子と値の対(ペア)を局所環境に追加すること(>>43 も参照)
ここで、追加の時に既に同じ名前の識別子が存在していた場合、手続き型言語では値を破壊的に更新するけど、
関数型言語では新たに局所環境が生成される(=破壊的に更新しない)点が異なる
ただし、この追加時の振る舞いの差異は、クロージャが存在する/しないとは無関係、ごっちゃにするのは間違い
- 78 ：
- >>74
たとえば JavaScript なら、ラムダ式だけ(>>53)と関数定義との併用、
それらのどちらでも簡潔なコードが書けるよ
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 だとラムダ式だけでは「入れ子になったカッコだらけ」の汚いコード(>>48)しか書けないから、
常に関数定義で「書かなければならない」という違いがある
- 79 ：
- >>77
お前のオレオレ定義なんて興味ねーんだよ
まずはその珍説が書いてある文献を引用しろ
- 80 ：
- >>78
>>45
- 81 ：
- >>78
関数定義で可読性も簡潔さも失わないから、関数で書ければ良いよ
で、なぜ関数定義でクロージャが作れる
Pythonにクロージャがない事になるの？
>>69にNoと答えて、>>65も否定したよね？
- 82 ：
- >>80
そいつ、関数を定義する特定のシンタックスシュガーに制限があることと
その言語自体が持つ機能との区別が付かない馬鹿だから
- 83 ：
- でもまあ、pythonの文法が変態なのは間違いない。
- 84 ：
- >>74
ナゼ 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 等々のふつうの言語では、
>>53 みたいなラムダ式だけを使ったコードが何の苦もなく自然に書けるんだから
- 85 ：
- 83はキチガイなの？
>>74は明らかに実行時のy,zを取り込んだ関数オブジェクトを生成してるからクロージャだろ
defと書くかlambdaと書くか文法の些細な決まり事などどうでもいい
- 86 ：
- >>84
同程度に簡潔に書けるなら、書き方は一つの方が良い
というのがPythonの理想だから
- 87 ：
- >>81
>で、なぜ関数定義でクロージャが作れる
>Pythonにクロージャがない事になるの？
>>73 で書いたように、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の
ふつうの言語では(関数定義だけではなく)ラムダ式でもクロージャが作られるという違いがあるからだ
対して、Python のラムダ式ではクロージャが作られない（だから、局所変数へ値を代入できない）
もし「Pythonにクロージャがない」という主張が不適切であるのならば、
>>43 の最後で書いたように、
「Python の言語設計者達は、処理系への実装を失敗した、あるいは言語設計上の欠陥を見落とした」
と言い換えてもいいよ
こんな使い物にならないラムダ式で満足しなければならないとは、最大の被害者は Python プログラマだよね
だって、他のふつうの言語であれば「ふつうに書ける」ことが、Python じゃ「書けない」のだから....(>>84)
- 88 ：
- ラムダ式の構文が残念だと言いたいなら、最初からそう言えばいいじゃん。
- 89 ：
- >>85
ラムダ式が引数に値を束縛できるのは、関数型言語を知っていれば常識だよ
そんなことも知らないの？
で、引数以外の局所変数に値を束縛するには、純粋なラムダ式に加えてクロージャが必要になるって話だよ
- 90 ：
- >ラムダ式が引数に値を束縛できるのは
それ束縛じゃねーだろ
キミはアホなのか？
- 91 ：
- >>89
>>74のy, zのどこが引数なんだよ
既知外は黙ってろよ
- 92 ：
- >>47の話ならデフォルト引数で値を入れてるから
普通に関数適用で引数に値を入れてるのとは厳密には違うよ？
どうでも良いけどね
- 93 ：
- >>87
Pythonにクロージャが無いは嘘ってことね
嘘は良くない
- 94 ：
- >>91
>>89で書いたのは >>42 のラムダ式だけで書かれた Python コードだ
失礼した
>>74 は関数定義でクロージャが作られているね
ただし、Python だけがラムダ式ではクロージャが作られず、
Python におけるクロージャの定義が他の「普通の言語」と異なっている事実に変わりはない
- 95 ：
- >>94
お前は無名関数って何がいいの？スレを立てて、そこで思う存分Pythonのlambdaを罵倒するべき
クロージャ云々は言いたい事と噛み合ってない
- 96 ：
- >>93
Python には真のクロージャが存在しない、という指摘は事実だよ(嘘ではない)
もし「Python にも真のクロージャが存在する」と主張したいのなら、
>>84 のコードが構文エラーとならないように添削しなさい
もし「Python にも真のクロージャが存在する」のなら、たやすい作業のはずだ
真のクロージャを備えた普通の言語では、何の苦も無く >>53 みたいなコードが書けるんだからね
君が嘘つきでなければ、書けるはず
- 97 ：
- 使い勝手で一番使い物にならないのはJavaだろ？
void m() {
int y = f();
y = y + 1;
new Thread(
() -> {ここでyを使えないKUSO言語}
);
}
- 98 ：
- ID:KOr7L+hP が言ってるのは、
関数の引数にもう少し複雑な処理をインラインで書きたいのに、
defは値返さねえし、lambdaは1行しか書けねえし、
まったく融通がきかねえな！
みたいな字面上の不満であって、関数型プログラミングだのクロージャだの全然関係ない。
- 99 ：
- >>96
関数は局所環境持ってても「真のクロージャ」じゃないってこと？
Yes/Noで答えて
- 100 ：
- 真のクロージャとかいうオレオレ用語
もちろん引用もなければ定義もない
- 101 ：
- >>95
クロージャという概念を正しく理解していないと、
Python みたいなラムダ式に欠陥のある言語が設計されてしまうというお話だよ
言い換えると、クロージャという概念を用いると、
なぜ Python のラムダ式が欠陥品なのかを明解に説明できる
このクロージャの利点は、このスレの主旨からは逸脱していないと思うよ
- 102 ：
- >>101
お前がこのスレで一番クロージャを理解してない件
構文の字面しか見てないし
- 103 ：
- >>99
No だね
あえていえば「クロージャもどき」とか「なんちゃってクロージャ」だね
真のクロージャであれば無名関数でも間数定義でも作られ、
無名関数であってもクロージャを構成する局所環境を持つことができる
これが、 C#、Java8、C++11、JavaScript、Ruby 等々の
「ふつうの言語」における「ふつうのクロージャ」だ
おそらくクロージャを正しく理解していなかったんだろね、Python 言語設計者達は....
- 104 ：
- 話をまとめよう
世間一般のクロージャの要件：
局所環境を持つ(変数を束縛できる)
関数をインラインで書ける
キチガイのクロージャの要件：
クソージャの中にクソージャが書ける
若しくは
言語設計上の欠陥を見落としたことを認める(>>87の発言)
のいずれか
- 105 ：
- >>104
添削してあげよう
--
話をまとめよう
世間一般のクロージャの要件（C#、Java8、C++11、JavaScript、Ruby 等々）：
関数であっても無名関数であっても、局所環境を持つ(変数を束縛できる)：>>53,56,77
Python に固有なクロージャの要件：
関数だけが局所環境を持つ(変数を束縛できる)：>>74
無名関数では局所環境を持てない(変数を束縛できない)：>>47,83
- 106 ：
- まあここはscheme最強っていう事にしておきますか。
- 107 ：
- >>102
> 構文の字面しか見てないし
だとすれば、Martin Fowler氏も「構文の字面しか見てない」ってもとになるんだろな
・Martin Fowler's Bliki in Japanese - クロージャ
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Closure
Lsip/Smalltalk/Ruby/JavaScript といったプログラミング言語では、
クロージャやブロックを多用したスタイルが好まれる
だから、Python みたいな無名関数で局所環境を持てない言語で同じようにクロージャを
多用するスタイルを試みると、「ラムダ式が入れ子でカッコだらけ(>>47)」な汚いコードや、
いちいち「関数定義しなければならない(>>74)」ケースと頻繁に出会うから、ストレスが溜まる
まあ「Python は手続き型言語」だから仕方ないんだよと自分に言い聞かせて我慢してるけど、
プログラミング言語を自由に選べるなら、真っ先に Python は除外するね、自分なら
もし、これが「構文の字面しか見てない」と思えるのなら、それはそれでもいいんじゃないのかもね.....
- 108 ：
- Pythonはlambdaの不便さも含めて構文がアレなので大嫌いだけど、
ライブラリが色々そろってて便利だから結局よく使っているのであった。
- 109 ：
- pythonのlambdaってmapやfilterを追加したときに申し訳程度に付けたって感じ
- 110 ：
- だね。Python使いはlambdaが互換性のためだけに残ってる欠陥品って認識あるから
デモとかどうしても1行で書きたいときしか使わんけど、
シンタックスシュガーの実体がlambdaな方面からするとそんな事情しらんしキモいかもね。
defで名前付きで書くのがふつうだし機能上困ってない。
- 111 ：
- >>107
その文章を書いた人の考えと、君の解釈には随分とズレがあるようだ
- 112 ：
- 馬鹿には無理
- 113 ：
- Pythonの不自由さ(関数型のクロージャに近いの)はGuidoの方針じゃないの？
嫌なら、おとなしくジェネレータ使えばいいじゃん。
- 114 ：
- クロージャは何がいいんだよ！
https://i.imgur.com/fTQTEYN.gif
- 115 ：
- 引数に別名付けたくなる程に中身が長いなら
関数にも名前付けろってのがGuidoの方針なんだろ
文法的に拡張可能なのに、あえてリジェクトしてるくらいだし
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
- 116 ：
- >>107
Martin Fowlerは字面だけを見てないから、ちゃんとPythonにもクロージャがあると思ってるよ
お前が張ったリンク先の「他の言語」を見てみろ
- 117 ：
- 何がクロージャかよりどこが好きかでクロージャを語れよ！！(ﾄﾞﾝｯ
- 118 ：
- クロージャとメソッドで f[x] と f(x) を使い分けなきゃダメなRubyが
一番ウンコだと思う
- 119 ：
- >>118
それはクロージャとメソッドではなく、Procとメソッドだと思う
Rubyのクロージャはブロックのほうの機能と考えたほうが良いんじゃないかな
- 120 ：
- >>117
俺の財宝か？欲しけりゃくれてやる。
探せ！この世の全てをそこに置いてきた。
- 121 ：
- 文系出身プログラマ「クロージャ？なにそれ？服入れるとこ？？」
ってやつに対してドヤ顔ができる
- 122 ：
- クロー系の最強魔法です 消費MP60
- 123 ：
- レスお願いします
- 124 ：
- 若い時に買ってでもすることは？
苦労じゃ！くろうじゃ！クロージャ！
- 125 ：
- クロージャの良さを、クロージャを使うことで劇的に
簡潔になる例を使って説明してください
- 126 ：
- コールバック関数を別途書かなくて良くなります。
もしコールバック関数の為だけにインスタンス変数を定義していたなら、
それも必要が無くなります。
消費MP 5
- 127 ：
- コールバック関数地獄のJSのコードは
可読性が悪い上に簡潔でも無いので、失格です
- 128 ：
- オールバックって額からハゲるだろ？
- 129 ：
- >>127
そんなあなたにClojureScript。
core.asyncのチャネルでスッキリしますよ（Go由来のようだけど）
- 130 ：
- >>129
コールバック自体がダメなんだよ。
例えば、addEventLisnerの引数にコールバックを指定する。
これだけでも可読性悪いだろ。
- 131 ：
- 見慣れてるかどうかだと思うけどな
- 132 ：
- >>130
代案も出さずに批判だけするなら、幼稚園児にだってできるよ
- 133 ：
- リスナーI/Fをインプリメントしたオブジェクト渡せばいいのでは
- 134 ：
- それではそのオブジェクトを定義しなくてはならなくなります。
クロージャはそのようなデリゲートオブジェクトやコールバックパターンからの解放なのです。
消費MP 12
- 135 ：
- JavaScript（だけに限らないが）
クロージャーが見難いんじゃなくて
非同期の入れ子が見にくいんだろ。
で、それを解決するライブラリが存在する。
結局のところ、そのライブラリ
Promiseとかを使えば解決する問題。
- 136 ：
- 結局のところ、コールバックはクロージャのメリットじゃないんですね？
もっと良い方法があるのですから
- 137 ：
- いや、クロージャ使ってそのスコープで解決しちゃえばコールバック関数要らないって話なんだが。
- 138 ：
- Haskellのdo記法みたいなのがあれば
クロージャをチェインしていっても読み難くならないという話ですか？
- 139 ：
- 小規模なコールバックだったらインラインで書いた方が見通しが良いだろうし、
複雑なのだったら分けて書いた方が理解しやすいだろうし、
あれが最強他はゴミとか言ってるのが一番ダメなんじゃね？
- 140 ：
- 結局クロージャの利点てコールバックが楽にかけるってだけ？
ならクロージャや匿名オブジェクトじゃなくて匿名メソッドが書ければ充分だな
- 141 ：
- 楽に書けるって事じゃなくて、そのスコープで完結できるって事じゃね？
- 142 ：
- とりあえずコードで語れば？
大規模開発でメリットが出てくるとかの話じゃないんだし
- 143 ：
- 見た目的にも変数の値の可視性的にもそこのスコープってとこが楽だよね
- 144 ：
- つまりインラインでクラス定義できるのでも良いわけだよね
- 145 ：
- >>144
本来そうだけど 、
シンタックスはインラインだけど実際はただの内部クラスで、
生成時の環境を一切利用できない言語もあるから何とも言えない。
クロージャの代わりにクラスを用いると何となくそういう実装になる。
ローカル環境の代わりにインスタンス変数を用いる方向にいくから。
FILE *fp = fopen(..);
doHoge( ^(const char*msg){ fputs(msg,fp); });
fclose(fp);
みたいに簡便にクロージャ生成時の外部の変数(の値のコピー)を
保持し使用できるクロージャとは方向性が違う。
ローカルメソッドに至っては環境が一昨渡せない
シングルスレッド前提ならグローバル変数を使えばいいわけだけど
- 146 ：
- (擬似言語)
fw = new FileWriter();
doHoge( fw.witer );
fw.close();
こんなのをワンラインで書ければ満足なんだろ？匿名メソッドで十分じゃない
- 147 ：
- >>146
じゃ匿名メソッドで書いてごらんよ
- 148 ：
- with (fw, new FileWriter()) {
doHoge(fw.witer);
}
こうやって書けるほうがいい
- 149 ：
- じゃあこれは？
FILE *fp = fopen(..);
doHoge( ^(const char*msg){ fprintf(fp, "Hoge: %s\n", msg); });
fclose(fp);
- 150 ：
- >>148
もはや匿名メソッドすら要らない派が出てくるしｗｗ
- 151 ：
- Java8すら使わせてもらえない人が必死なスレにしか見えなくなってきた
- 152 ：
- >>146,147
それだと doHoge の実行中に例外が発生するとファイルがクローズされない
たとえばクロージャを多用する Ruby のような言語だと、以下のように書く
File.open(..) do |file|
doHoge do
file.puts(msg)
end
end
Ruby ではクロージャをブロックと呼ぶけど、ブロック実行中に例外が発生しても
ファイルは確実にクローズされるし、ユーザ定義メソッドでも同様な振る舞いを実装できる
>>148
それに対して、クロージャを持たない手続き型言語の Pascal や Python といった言語では、
同じ事をするのに(>>148 のような) with 構文を使わなければ書けない
クロージャは一級市民だから引数で渡したり呼び出すことができるという自由があるけど、
with 構文はあくまで文(statement)だからクロージャと比較すれば表現力は制限される
いわばクロージャという概念を持たない言語の代用品が with 構文である
なおJavaScript はクロージャと with 構文のどちらも持っているけど、
書籍 "JavaScript: Good Parts" だとクロージャは Good Parts に
with 構文は Bad Parts に分類されている
- 153 ：
- クロージャばりばり使うlisp方言でもwith構文は使うよ
- 154 ：
- クロージャとクリーンアップ処理とは別の話じゃないの？
- 155 ：
- Pythonが憎すぎて既知外になった人の相手をしちゃいけません
- 156 ：
- >>152
> なお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になってるわけじゃない
お前、ほんと、馬鹿だよね？
- 157 ：
- クロージャと with 構文のどちらも持っている言語であれば、
ケースバイケースで可読性や好みで使い分ければいいのではないかと
問題はクロージャを持たない、あるいは
「世間一般のクロージャの要件(>>105)」を満たせない言語では、
with 構文という(クロージャと比べて)不自由な代用品を使わざるをえない
という話
- 158 ：
- >>152>>157
下の(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って字面だけ見て同じだと思っちゃったの？
そんなだから構文の字面しか見てない馬鹿って言われちゃうんだよ
- 159 ：
- >>156
>ここで言ってるwithは例外が起きた時にリソースを解放する機能を持ったもの。
わざわざ with という構文を追加して言語の意味論を複雑にしなくても、
もし汎用的な概念であるクロージャがあれば、同じ事を実現できるってことだよ
もし Python にもクロージャがあるなら、他の言語達と同様に
with 構文を使わなくてもリソースの自動解放を簡潔に表現できるハズだけど、
手続き型言語の Python では無理だろうね
それとも、書けるかな？
- 160 ：
- pythonでも引数にクロージャ受け取ってwithの中でそれを実行する関数つくれば、rubyのそれと等価じゃね？
pythonはlambdaが制限きついから複雑な処理はインラインには書けないけど。
- 161 ：
- >>160
>それを実行する関数つくれば、
もし Python が「世間一般のクロージャの要件(>>105)」を満たしていれば、
「関数をつくらなくても」クロージャだけで簡潔に書けるはず
つまり「関数をつくらなければ書けない」ということは、
Python が「世間一般のクロージャの要件」を満たしていないことを認めたってこと
- 162 ：
- 「世間一般のクロージャの要件」が
全然世間一般の定義じゃない件
- 163 ：
- >>161
def make_f(x):
def f(y):
return x * y
return f
例えばこんなのがあったとして、このmake_f()が返すものは何？
- 164 ：
- >>163
「クロージャみたいなモノ」もしくは「クロージャもどき」
def make_f(x):
return lambda(y): x * y
が返すのも同じ
- 165 ：
- >>164
「クロージャみたいなモノ」もしくは「クロージャもどき」と、クロージャの違いは何？
- 166 ：
- >>164
>>32の定義だと完璧にクロージャの条件を満たしてるけど？
君はどこのローカルルールの話をしてるの？
- 167 ：
- >>165
>>105
- 168 ：
- >>167
＞世間一般のクロージャの要件（C#、Java8、C++11、JavaScript、Ruby 等々）：
＞ 関数であっても無名関数であっても、局所環境を持つ(変数を束縛できる)：>>53,56,77
>>163のmake_f()が返すものは局所環境をもってるし名前も付いてないよ。
- 169 ：
- >>166
いや、Python は関数を定義しなければ局所環境が作られないんだから、
>>32 の要件は満たしていないだろ
>>32 には「ラムダ式や無名関数で実現している」と書かれているんだけど、
日本語が不自由なんですか？
実際、もしも >>32 の定義を満たしているなら、
>>47 のゴチャゴチャしたコードは
(>>74 のようにわざわざ関数を定義しなくても)
>>84 のように「ラムダ式や無名関数で実現している」
簡潔なコードに書き直せるはずだ
さて、論よりコード、>>166 は書き直せるかな？
- 170 ：
- 今の議論と全然関係ないんだけど、久しぶりに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
- 171 ：
- >>169
>>32には「いくつかの言語では」と前置きされてるじゃん
つまりラムダ式や無名関数は必要条件ではない
そっちこそ日本語が不自由すぎるのでは？
- 172 ：
- >>168
それは def f(x): で関数を定義しているから、当たり前の話
「世間一般のクロージャ」であれば、わざわざ関数を定義しなくても
ラムダ式や無名関数と呼ばれる構文でクロージャを作れるんだよ
>>32 をよく読み直そうね
- 173 ：
- >>172
じゃあさ、これが返すものは何？
(define (make_f x)
(define (f y)
(* x y))
f)
- 174 ：
- >>172
> >>32 をよく読み直そうね
お前が100回読み直した方が良いぜw
- 175 ：
- >>171
>>32 にある「いくつかの言語では」という前置きは、
後から出てくる Smalltalk や Ruby のブロック構文を指すと
考えるのが自然じゃないかな？
さすがに Wikipedia のページ著者が
「ラムダ式や無名関数」と「関数定義」との違いも
分からないほどのお馬鹿さんだとは思えないしね
- 176 ：
- >>173
ごめん。それで (make_f 10) とか実行した時に返ってくるもの、の間違い。
- 177 ：
- >>173
クロージャだね
(define (make_f x)
(lambda (x) (* x y))
)
が返すのもクロージャだね
- 178 ：
- >>177
>>163のpythonのコードと完全に同じなんだけどw
- 179 ：
- >>175
> さすがに Wikipedia のページ著者が
Wikipediaの編集者を持ち上げるのは良いけど、
お前の主張とは違う事が書いてあるぜ
読めるか？Pythonって書いてある
> クロージャを持つ言語に、C# 3.0、C++11、ECMAScript（JavaScriptを含む）、Groovy、Java 8（予定）、
> Perl、Python、Ruby、PHP（5.3以降）、Lua、Squirrelなどがある。
- 180 ：
- >>179
Wikipedia の記事が常に 100% 正しいと思っているのかな？
記事の冒頭にある >>32 のクロージャという用語の定義とは
矛盾していると思うけどね
（自分のクロージャという用語の定義は >>4 で書いた）
もし矛盾していないと反論したいのなら、論よりコードだ
>>47 のゴチャゴチャしたコードは
(>>74 のようにわざわざ関数を定義しなくても)
>>84 のようにラムダ式や無名関数だけで書き直せるはず
さて、>>179 は書き直せるかな？
- 181 ：
- >>180
>>171が正解と考えれば全く矛盾してないので、お前が間違ってるんだよ
- 182 ：
- with構文はスコープから抜ける時にclose的な関数を必ず呼び出してくれる保証があるけど、
Rubyのブロックにはそんな保証は無い
だからRubyではウッカリcloseを忘れても分かりにくい
そういうのは良くない
- 183 ：
- >>180
> Wikipedia の記事が常に 100% 正しいと思っているのかな？
思ってないけど、あんたが言っていることよりかは
正しいと思うね。
だって、あんたの言うことのほうが正しいなら
wikipediaを修正すればいいわけだから。
- 184 ：
- なんだ、この偏執狂たちの罵り合いはw
そんなことより、問題。
若い内に買ってでもしろ、と言われるものはなぁんだ？
- 185 ：
- ああ、let-inが無いからpythonのはクロージャじゃないって主張か。
斜め上だな。
- 186 ：
- 環境と変数を手軽に包めるのは有難いけどなあ
XMLベースのジョブ管理言語とか
ちょっとしたVM作るときに
継続の表現にクロージャなしだとだるいよ
さらに無名クラスも無い言語だと
本物のVM作らなきゃいけなくなる
- 187 ：
- https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Closures
- 188 ：
- >>184
セックス…かな
年とると立たなくなるから
- 189 ：
- >>188
ご愁傷さまです。
- 190 ：
- >>190
？
- 191 ：
- Swift スレでクロージャの話題で荒れそうだったので、こちらへ移動しとく
http://peace.2ch.sc/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.sc/test/read.cgi/tech/1345123070/70-71
これが Swift や Ruby 等と比較すると、関数型プログラミングで Python が劣る典型的な一例になる
- 192 ：
- と言うかどう見てもこないだまでこのスレに居た俺俺定義の人ですな
- 193 ：
- よく見たら、そのスレで誘導かけてるの、話振ったお前本人じゃねーかw
俺俺定義が認められなかったから逃げて来たのか？
- 194 ：
- クロージャの定義は>>4って書かれてたがStandard MLにラムダ式はない
けど当然SMLにはクロージャがあるわけで
ソースはThe Definition of Standard ML, revised edition
- 195 ：
- 関数型プログラミングってどういうのを指して言ってるんだろ
- 196 ：
- >>191のサンプルが手続き型全開の書き方で笑った
>>195
関数（に名前付けたくない）型プログラミング
- 197 ：
- >>193
Swift スレの質問「Python が Swift や Ruby より劣ってるのは何か」に答えただけ
で、具体的に反論できないから罵倒を始めて Swift スレが荒れそうだったから、
こちらへ移動してきた
>>194
>>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
- 198 ：
- >>197
肝心のクロージャの定義の引用はまだですか？
俺俺定義はお腹いっぱいなんですよ
- 199 ：
- 調べてみると、Python のラムダ式で任意の文が書けないという問題(>>191)は、
過去に何度もネット上で話題になっていたようだね：
・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.sc/test/read.cgi/tech/1417333026/9
- 200 ：
- >>191
普段Python書かないからPythonicではないかもしれないが、だいたいこんな感じだろう。
http://ideone.com/0vAET2
それで、何が問題なんだ？
- 201 ：
- >>198
ではクロージャ定義の引用元ソースを示そうね
答えは書籍「計算機プログラムの構造と解釈」、いわゆるSICP本だ
その中の節「3.2.1 評価の規則」に手続きオブジェクトが、いわゆるクロージャに対応する
http://sicp.iijlab.net/fulltext/x321.html
そしてクロージャを視覚化したのが、
このページの図3.2にあるオタマジャクシの卵が２つ並んだ図形になる
単純な話だと思うけど、難しいかな？
- 202 ：
- >>200
関数を宣言せずに書くという制約の元ですから、とてもPythonらしいコードだと思います
しかもループの代わりに関数再帰を使っているのですから、より関数型プログラミングらしいとも言えます
ただし、元々 Swift で書かれていたサンプルコードを各 LL へと書き直しているのですから、
もし以下の点を改善できれば(Pythonらしさという意味では)完璧でしょう：
・中間変数 f を宣言せず、リスト内包式の中にラムダ式をインラインで書く
・Swift のコードは辞書を使っているのですから、それを(勝手に)配列 digits へ改変せず、
Python でも(Ruby や JavaScript と同様に)辞書を使って書く
- 203 ：
- >>202
注文が多いな。
http://ideone.com/KWnSgA
- 204 ：
- >>201
で、どこに「クロージャは無名関数でなければダメ」と書いてあるの？
「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが？
いい加減、誤摩化して逃げ回るのは止めたら？
- 205 ：
- 以前も書いたけどPythonistaは走り書き以外でlambdaなんて使わないから。
- 206 ：
- 別にPythonのラムダに式が書けないから問題だと言うだけなら荒れねーよ
そこで「だからPythonにはクロージャが無い」って言う
決して成り立たない等式を持ち込むから「いやそのりくつはおかしい」って言われてんのに
そしたら既存のクロージャという用語の定義のほうを弄ろうとするから叩かれてんだろうが
プログラミングに例えるなら、お前は自分の書いた関数で
組み込み整数型の値にそのままリスト処理を適用しようとして例外吐かれたから、と
整数クラスのほうがリストとして振る舞うようにメソッドを書き換えようとしてる
- 207 ：
- >>203
お疲れさまです
中間変数 f は消えましたが、今度は中間変数 applyf が現れてしまいましたね....
- 208 ：
- >>207
http://ideone.com/zAN4uA
- 209 ：
- >>207
とりあえずクロージャの定義を貼っておきますね
反論よろしく
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.
- 210 ：
- >>204
> で、どこに「クロージャは無名関数でなければダメ」と書いてあるの？
もちろん「クロージャは無名関数でなければダメ」とは書かれていない
同時に「ラムダ式に文が書かなくともクロージャである」とも書かれていない
SICP本を理解するには、記述されている定義から類推によって解釈できる知性が必要だね
>「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが？
この節で記述されているのはクロージャの一般的な概念であり、特定の言語や実装には限定されない
ここで記述されている概念に沿って設計された言語であれば、たとえば：
・Scheme なら (lambda (x) .... ) で、
・Standard ML なら fn x => .... で、
・JavaScript なら function(x) { ..... } で、
・Ruby なら proc { |x| .... } で作られる
ここで.... の部分には、破壊的代入や入出力等の副作用を伴う任意のコードが書ける
唯一、書けないのは Python だけ
で、どこに「Schemeという特定の言語」と書いてあるの？
いい加減、誤摩化して言い逃れをするのは止めたら？
- 211 ：
- >>208
ありがとうございます、これで完璧ですね
これで「何が問題なんだ？(>>200)」という議論を続けることができます
具体的には、>>191 の Swift/Ruby/JavaScript で書かれたコードと
>>208 の Python で書かれたコードを比較して、
「どちらがわかりやすいか/読みやすいか/書きやすいか？」という話です
で、これらは主観による評価ですから、
いくら議論しても誰もが納得できる結論へとは収束しないでしょう
すべての Pythonista にとって >>208 が読みやすく書きやすいと感じるのなら、
それはそれでいいんじゃないでしょうか
- 212 ：
- 一時変数を消すためにそんなパズルみたいな事やって読みやすいわけないだろw
- 213 ：
- >>210
schemeではlambdaが本質的なもので(define (f x) 〜)はシンタックスシュガーだけど、
pythonではdefが本質的なものでlambdaの方がシンタックスシュガーなのでは。
- 214 ：
- >>209
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本(>>121) および >>4 のそれと矛盾していない
そして Haskell のような純粋関数型言語に限定した文脈ではないのだから、
文中の "function code" は(>>210 で書いたように)単なる式だけではなく
破壊的代入や入出力等の副作用を伴う任意のコードも書けると解釈するのが自然だと考える
- 215 ：
- >>4
>クロージャを識別子に束縛したものが一般的な「関数宣言」である
よかった、pythonにもちゃんとクロージャあった
- 216 ：
- foo = lambda bar: bar
これはクロージャである
っていうのが偽であることを定義から証明すればいいんじゃないかな
反例あげればいいだけだよね？
- 217 ：
- あ、まちがえたそれはクロージャじゃない
def foo():
bar = 1
これに訂正
- 218 ：
- >>211
それはPythonの書き方じゃないんだよ。
お前が>>202で指定したから、結果的にそうなっただけで。
それで、結局「クロージャを書けない」から「読みにくい」に問題をすり替えて終わりか？
- 219 ：
- http://ideone.com/C5hOIB
- 220 ：
- イデオンこわい
- 221 ：
- >>210
> もちろん「クロージャは無名関数でなければダメ」とは書かれていない
なんだ、Pythonのdefで良かったんだ
知らないみたいだから教えてあげるけど、Pythonではdefで関数定義すると
環境を持ったクロージャになってるんだよ、勉強になったね
- 222 ：
- >>211
>>203のapplyfは、特定のロジックに依存しない汎用的な関数だけど、
こういうものの定義や使用も認めないってことは
ライブラリによる拡張も否定するってことでOK？
ライブラリを使わないと外部イテレータが使えないRubyをdisってるの？
- 223 ：
- >>210
書かれてない要素を勝手に追加するから
オレオレ定義って言われるんだよ
クロージャの定義には無名関数であることも、文が書けるor書けないことも、
含まれてないんたから、勝手に条件に追加すんな
- 224 ：
- >>220
>>219 はPythonのlambdaからでも副作用を伴うメソッド呼べますよってコードだな
- 225 ：
- >>213
本質という言葉の定義が曖昧ですが、自分なりにコメントします
まず >>209(= Wikipedia, >>214)の章「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 は手続き型言語だから」ということですね
- 226 ：
- >>225
本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。
first-class valueってのは、変数に代入したり、関数の引数に渡したり、
関数の値として返したりできるオブジェクトの事だよ。
def だの lambda だのっていうのはそういうオブジェクトであるクロージャを作り出すための構文だよ。
pythonは手続き型言語だっていうけど、そんなの当たり前だろw
rubyだのjavascriptだのだって手続型言語だよ。
- 227 ：
- >>226
> 本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。
その意味であれば、関数型言語と Ruby/JavaScript だと
関数定義よりもクロージャのほうがが本質的だね
プリミティブな名前とクロージャから関数(or メソッド)が作られるという
因果関係があるのだから
ただし、Python だけは違うみたいだね
> rubyだのjavascriptだのだって手続型言語だよ。
外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている
だから最初から関数型言語と同等なクロージャを備えて誕生した
それが知られるようになったのは最近だから、知らない人は多いけどね.....
手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ
http://peace.2ch.sc/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 がいくら挑戦しても勝てずに負け続けているのは、
> しごく当然な結果なわけ
- 228 ：
- ＞外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている
S式で表現されてなきゃlispじゃねえよ。
- 229 ：
- だいたいlispが関数型言語だって言うことにも抵抗がある。
- 230 ：
- >>227
>手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ
自己レスで補足する（すべての手続き型言語が Python と同じではない....
同じ手続き型言語に関数型の特性を追加した言語でも、
調べた範囲だと少なくとも Perl5/Java8/C++11 のクロージャは
・>>4,>>121 のクロージャ定義に沿って設計され、
・クロージャ内で任意の文が書ける
ただしそれら言語がクロージャをサポートした時期は遅かった
真面目に設計したからだろう
対して Python の関数型サポートは素早かったけど、検討が不十分だったと言うほかない
リリース後に改善要望/議論紛糾したあげく、結論を出せず現在に到る(>>199)
- 231 ：
- 横だけど、
Rubyのブロックはラムダじゃないしファーストクラスでもないよね
？
メソッドにラムダを渡すこともできるけど、不格好なんだが？
これって、ここのオレオレ定義にてらすとどうなの？
なんだか、ラムダに文を書けない（書かない）ようにしている
Pythonの仕様をあげつらうためだけにオレオレ定義をこねくって
悦に入ってるPythonアンチがいるって感じがするだけなんだが。
- 232 ：
- Rubyのブロックの中に副作用をジャンジャン書いて
それを繋げるスタイルを関数型と言われても困るわ
文推奨の時点で関数型とは言い難いわけだし
- 233 ：
- オレオレクロージャ君は言葉が通じないし、
必死でググった的外れで糞長い引用でしか反応しないし、
相手するだけ無駄。
- 234 ：
- うん、ただのPythonアンチでしか無いと思うよ。
Ruby好きでPython嫌いな俺は、Pythonのlambdaが使いにくいのには同意するが
そのためにクロージャの定義のほうを捻じ曲げるのは、ありえないと感じるよ。
そもそも、その定義だとRubyどーなんねん、と思うし。
Rubyには「他言語の関数」に相当するものがなく、
一定の条件を満たし、見かけ上、関数のような呼び出しが可能なメソッドを
便宜的に「関数」と呼んでいるだけだし。
クロージャはブロックという形で存在はしているが、
彼の言う定義に従うならブロックはファーストクラスでなければならない。
でもRubyのブロックはファーストクラスとは言い難い。
lambda関数(実際はもちろんメソッド)が返すのはProcクラスのインスタンスだけれども、
ブロック.is_a? Procインスタンス では無い。そしてメソッドや、ましてや関数でもない。
そもそもブロック単体では値としては取り回せないからProcクラスがあるんだし。
- 235 ：
- オレオレクロージャ君って少し前に某スレでPython disってた人にそっくり
- 236 ：
- lambda
ラ…ランバダ…
- 237 ：
- >>236
もっと勇気をもって！
ランバダ！
- 238 ：
- ,-----、
/ ヽ.
| (･) (･) |
／ヽ￣ ￣ﾉヽ
/ ヽ＿＿＿＿＿/ ヽ
| / ｌ | |＼
| | 。ノ ヽ。 .|＿＿_| ＼
ヽ＿__ヽ + ﾉ,､_､_､_ヽ ＼
| ヽ|￣￣￣￣ | ;;;;;;;;;;;;;;;＼＿ ﾉ
< ````/＼ ／＼;;;;;;;;;;;;;;;;;/
ヽ;;;;;;| ＼＿/ ヽ;;;;;;;;;;;ﾉ
￣.|＿__/ ＼＿＿)￣ .＿＿__
/ | | | ＼ ／
（＿＿_| |＿＿）＝＝＝⊃
勇者の父 ランバダ
- 239 ：
- 無駄にMP消費していざという時に足りなくなって犬死にする無能
- 240 ：
- >>231
>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(>>201) の関数型言語におけるクロージャ定義に当てはめれば
「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 のクロージャ定義の引用元(ソース)は >>201 で示したが、まともな反論はない
むしろオレオレ定義と騒ぎ立てていた連中がSICP本を読んだ事もないお馬鹿達だったのでは？
あるいはSICP本を読んでいなくても、関数型言語の操作的意味論や処理系実装の知識があれば
>>4 がオレオレ定義でないことは直ぐに理解できていたはず
- 241 ：
- >>240
後から言い逃れようとしても、掲示板にはログが残ってるから無駄ですよ
>>99に対する>>103の返答の時点で、何も分かってなかったのは明らか
- 242 ：
- >>240
RubyのブロックはProcクラスのインスタンスではないよ
ブロックそのものは、メソッド呼び出し文法の一部でしかない
そのブロックを、それのみで値として扱うためのラッパがProc
- 243 ：
- Rubyistは全員クロージャを間違った解釈してるのか？
それとも、奴だけなのか？
そこが気になるな。
- 244 ：
- >>232
残念ながら 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| .... } # >>191 を参照
それに対して、Python 伝統的な関数適用スタイルでは：
・データの流れ(いわゆるデータフロー)とメソッドの並びが逆転し、
・カッコが入れ子になる
reduce(lambda n, r: ...., 0, map(lambda r: ...., filter(lambda r: ...., table)))
どちらを優れているか？という評価は主観だから、各自で判断してもらいたい
（まだ続くので、ここで切る）
- 245 ：
- >>241
次に、関数型プログラミングと(文の評価によって起こる)副作用との関連について
まず関数型プログラミングで副作用は推奨されていない
基本的には map/filter/reduce (Ruby では map/select/inject) といった高階関数を使った
(副作用の無い)参照透明性のあるコードが推奨されている
これは >>244 の文書「Rubyによる関数型プログラミング」で具体的なコード例を使って解説されている
おそらく誤解したのは >>191 の Swift/Ruby/JavaScript コードで while 文と
ローカル変数への破壊的代入を用いていたのを見たからだと思うけど、
これは、「わざわざ」副作用を使った手続き型プログラミングほうが簡潔になる「お題」を選んだからだ
実際、副作用の代わりに再帰を使った Python コード >>208 は「普通のプログラマ」には分かりにくい
（Python だけでなく、この「お題」は Ruby であっても再帰を使えば同じく分かりにくいコードになる）
また(Ruby を含む)大半の手続き型言語処理系だと、TCO(末尾再帰最適化)は実装されていないか不完全である
だから手続き型言語における関数型プログラミングにおいて、
再帰プログラミングには(分かりづらいだけでなく)実用上の制限があるから
ツリーのような再帰的データ構造の探索問題などに限定して利用すべき（上記文書の節「再帰」を参照）
これらの判断について、上記の文書では以下のように記述されている(節「おわりに」から引用)：
「Rubyは基本的には命令型言語であるけれど、 関数型プログラミングへの際立った潜在能力があるのだから、
それらをいつどのように使うか(そして、いつ使わないか)を知っておくべきである。 」
- 246 ：
- もうみんなgaucheに改宗しようぜ
- 247 ：
- >>234
>Rubyには「他言語の関数」に相当するものがなく、......
これは(>>240 に書いたけど)、まったくそのとおり
>でもRubyのブロックはファーストクラスとは言い難い。
ここの「....とは言い難い」という文章表現は曖昧だね
（なぜ「....ではない」と断定的に言い切れなかったのだろうか？）
まず >>240 で書いたように、Ruby の「ブロック付きメソッド呼び出し」は構文糖だ
（対して、簡潔な構文を追求した Smalltalk では、常にブロックはオブジェクトである)
これを構文糖にした理由の一つはメソッド呼び出しコードを簡潔にする目的(>>240)であるが、
ブロックを多用する Ruby のプログラミングスタイルでは、ブロックを評価するたびに
Procオブジェクトを生成していたのでは実行効率の面でオーバヘッドが大きいという理由がある
このためRubyインタプリタの内部だと、
ブロックは(重いオブジェクトを表すC構造体ではなく)専用の軽量なC構造体で表現されている
ただし、(たとえ内部表現が Proc オブジェクトと異なっていても)プログラマから見れば問題にならない
なぜなら、渡されたブロックをいつでも Proc オブジェクトへ変換できる構文糖が最初から用意されているから....
たとえば foo(x, y) { |z| .... } という「ブロック付きメソッド呼び出し」に対して(>>240)：
・def foo(x, y); .... ; end
・def foo(x, y, &block); .... ; end
という２つのメソッド定義は「いつでも」交換できる
まとめると：
Ruby のブロックは内部表現だと Proc オブジェクトではないが、
プログラマ目線ではファーストクラスのオブジェクトとして扱うことができる
- 248 ：
- gaucheいいよね
- 249 ：
- >>241
つまり「Ruby のブロックはクロージャである」という初歩的なミスについて、
>>103 をレスした時点から数えて >>231 が指摘するまでの間には
誰一人気付けなかった事実が「掲示板にはログが残ってるから明らか」になるわけですね
た い へ ん わ か り や す い で す
- 250 ：
- 最近はほぼgaucheでしかプログラム書いてない。
もう止められない体になってしまった。。。
- 251 ：
- 俺、numpyとscipyとopencvのサポートがgaucheにくっ付いたら、python捨てるんだ！(遠い目
- 252 ：
- common lisp処理系の方が速いのあるしライブラリも充実してるし良いよ
- 253 ：
- ループしないで全部再帰で書きたい
- 254 ：
- lisp-2なのが何となく嫌
- 255 ：
- >>253 いいよ
- 256 ：
- >>249
だってRubyなんてマイナー言語どうでも良いし？
- 257 ：
- >>243
こいつだけです。と言うかRubyに対しての知見も怪しい
>>247
Rubyのブロック付きメソッド呼び出しのほうを構文糖と。またオレオレ定義？
「ブロック付きメソッド呼び出し」は文法だ、これはlambdaより先に実装されてる
そのブロック部分のみを扱うためにProcクラスもlambdaより先に実装されていて、
そのProcを簡便に扱うためにlambdaと言う構文糖が後から出来た
と言うか「ブロック付きメソッド呼び出し」、昔は「イテレータ呼び出し」だった
イテレータ呼び出しを汎化した結果生まれたのが、ブロック付きメソッド呼び出し
その時代からmapやselectなどの
今で言う関数型的なメソッド群を実装するモジュールEnumerableは
「これをincludeするクラスにはeachメソッドを実装すること」としていた
もしRubyが関数型として設計されていてProcが主なら
call必須なんてことにはしなかっただろうし
関数がメソッドの一種なんてことにはなってない
そしてEnumerableはeachではなく、Array辺りを要求する高階関数群だっただろう
RubyはOOPLとして設計され、それが主で
関数型プログラミングは結果として付いてきた
そこでProcに関数型のラムダ的な挙動を付加し生成するlambdaも出来たんだよ
- 258 ：
- >>244
> また Ruby の「ブロック付きメソッド呼び出し」とそれらを並べる(=チェーンさせる)スタイルは、
> Apple の新言語である Swift にそのまま採用された
Obj-C が inline Smalltalk が書ける C なのに、Swift が Ruby をまねたみたいなデマはやめてくれる？
それと、 Ruby で関数型スタイルのプログラムを書けるということを、Ruby で書いたら関数型プログラムになるかのように書くのもやめてくれる？
- 259 ：
- 主観を事実であるかのように語る客観性の無さ
オレオレ定義の根拠を問われて自身の過去の書き込みを引用するコミュニケーション不全
完全に論破されると、自分の間違った主張を相手が言い出したと歴史歪曲しようとする卑怯さ
全てを兼ね備えると>>244みたいな奴になる
- 260 ：
- >>257
>そのブロック部分のみを扱うためにProcクラスもlambdaより先に実装されていて、
>そのProcを簡便に扱うためにlambdaと言う構文糖が後から出来た
lambda はメソッドであって、構文糖ではない
>>234 では「もちろん(lamda は)メソッド」と主張しているから、もしも同一人物のカキコなら矛盾している
いったいどちらが正しいの？
>イテレータ呼び出しを汎化した結果生まれたのが、ブロック付きメソッド呼び出し
その「汎化」とは具体的には何を指しているのかな？
もともとイテレータという概念と用語は手続き型言語 CLU で生まれ、Ruby でも採用された
ただし CLU のイテレータは for ... in 構文というループ処理での利用に制限されたのに対して、
(クロージャとしての)ブロックを備えた Ruby ではループ処理以外にも利用できる形で「最初から設計された」
・Rubyist のための他言語探訪 【第 2 回】 CLU
http://magazine.rubyist.net/?0009-Legwork
このためループ処理でもないのにイテレータ(iterator, 反復子)という用語は紛らわしいという声が挙り、
用語「イテレータ呼び出し」は「ブロック付きメソッド呼び出し」へと名称が「後から変更された」
つまり単に用語の命名が「後から」改められだけで、言語仕様の基本は「最初から」何も変わっていないはずです
>RubyはOOPLとして設計され、それが主で関数型プログラミングは結果として付いてきた
スマンが、いいかげん説明は面倒なので以下を読んでください
・Lisp から Ruby への設計ステップ
http://yohshiy.blog.fc2.com/blog-entry-250.html
ただし、もともとメソッド lambda は proc の別名で同じ意味でしたが、
1.8 の時代に lambda の挙動が変更されメソッドとして独立しました
その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません
言語仕様として「関数型プログラミング向けに後から追加/変更」されたのは、自分の記憶だとコレくらいしかありません
- 261 ：
- 俺が平安時代に読んだ本だと、iteratorはアイテレータって書かれてたな。
あとhierarchyはハイアラーキだった。
- 262 ：
- そんなにlispに憧れてるなら、lispを使えばいいのに。
- 263 ：
- > 1.8 の時代に lambda の挙動が変更されメソッドとして独立しました
> その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません
RubyのProc.newで作られるオブジェクトは
returnの挙動が普通の関数と違ってキモすぎるので
lambdaの方だけでも普通に直したんでしょう
- 264 ：
- さらに言えば、Rubyのブロック変数のスコープの扱いが1.9で仕様変更されてるけど、
それについてmatz自身が
> それは、Rubyが最初から関数型言語としてスタートしてないからであって、言語が違うからですよね。
と語っているね
http://www.atmarkit.co.jp/news/200907/24/ruby.html
- 265 ：
- >>258
>Obj-C が inline Smalltalk が書ける C なのに、Swift が Ruby をまねたみたいなデマはやめてくれる？
スマン、ここは説明が足りなかった、Tailing Closure のことを言いたかった
Objective-C を含むほとんどの言語では、引数をカッコで囲んで関数(or メソッド)へ渡す文法になる
基本的には Swift も同じですが、引数リストの最後がクロージャである場合に限り、
そのクロージャ引数を閉じカッコの直後に置く事ができます
・collection.map({ ..... }) // 一般的(常識的？)な書き方
・collection.map() { ..... } // クロージャを引数リストの直後へ移動できる
・collection.map { ..... } // さらには丸カッコ () も省略できる
これを Ruby で書くと、以下のようになります
・collection.map(lambda { ..... }) # Ruby だと一般的ではない
・collection.map() { ..... } # ブロックを引数リストの直後へ移動できる（ブロック付きメソッド呼び出し）
・collection.map { ..... } # さらには丸カッコ () も省略できる（これが普通の Ruby らしい書き方）
これと同じ書き方ができる言語を Swift と Ruby の他に自分は知りません
そして発表時期的に Ruby の後に Swift が生まれたから、ここは Ruby の影響ではないかと「推測」しました
Tailing Closure の由来に関するソースは持っていないので、デマと言われてもしかたがありませんね....
>それと、 Ruby で関数型スタイルのプログラムを書けるということを、Ruby で書いたら関数型プログラムになるかのように書くのもやめてくれる？
Ruby は手続き型言語なのだから、プログラマが意識しなければ関数型プログラミングのスタイルにならないのは当たり前
いいかげん説明は面倒なので、以下の文書をよく読んでください：
・Rubyによる関数型プログラミング
www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html
もし具体的な疑問/質問があれば、個別に返答します
- 266 ：
- >>263
おそらくその通りだと思います
>>264
もしも Matz が Lisper ではなく Schemer であったなら、
違った結果になっていたかもしれませんね
- 267 ：
- 自己レスになりますが、>>245 では：
> （Python だけでなく、この「お題(>>191)」は Ruby であっても再帰を使えば同じく分かりにくいコードになる）
とカキコしました
で、後から考え直して「手続き型のループ＆破壊的代入」ではなく、しかも「関数再帰」も使わずに、
参照透明性がある関数型プログラミングのコードを考えてみました
http://ideone.com/UrfbuL
ポイントは「反復に組み込みメソッド loop」を「ブロック脱出に引数付のbreak文」を使った２点です
なおメソッド loop は一般に loop do .... end という手続き型のスタイルで書かれることが多いために
ループ構文の一種と誤解されがちですが、（lambda を構文糖であると >>257 が 勘違いしたように....）
loop はメソッドですので(コードで示したように) inject へチェーンさせることができます
また「参照透明性はあっても、手続き型の制御構造であるbreak文の利用は反則ではないか？」という
指摘を予測して、
同じスタイルで(break文の代わりに)組み込みメソッド catch と throw を使ったコードも書きました
http://ideone.com/SaCAFi
ただし、この catch/throw は大域脱出のために用意されたメソッドですから、
今回の「お題」のように単一ブロックを脱出するだけならbreak文を使うのが素直だと考えます
ついでに(catch/throw の代わりに)Scheme 由来の継続(continuation)を使ったコードも書きました
http://ideone.com/5t1VEq
- 268 ：
- こんな無駄に遠回しなコード沢山書いてどんだけオナニー好きなんだよ。
- 269 ：
- >>200の爪の垢でも煎じて飲めよ。
- 270 ：
- >>260
もちろん、本当はただのメソッドであってlambdaは文法要素ではない
あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、その対比としてそう書いたまでだよ
分かりにくかったね、「構文糖のような存在のメソッド」と修正しておくよ
- 271 ：
- まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら
「真のクロージャ」って用語もおかしいのだと気付いて欲しいな
- 272 ：
- なんか知らんけど伸びてて嬉しいです
目標はGCスレ超えです
- 273 ：
- 一応lambdaというメソッドの実装された時期について調べてみたら、結構昔から存在自体はしてたのね
元々procと同じなのに字数多い&Procなのにlambdaって覚えにくいのと1.4当時は関数型とか知らんかったからスルーしてたのかな
そこは俺の記憶違いだったわ
- 274 ：
- クロージャがなければ参照カウント型のGCで済むんじゃないか説があるし
ワンチャンあるよ
- 275 ：
- 構文糖衣とかいいながら
ラムダって名前から甘そうな印象をうけない
名前が悪いよ考え直すべき
- 276 ：
- クロージャって名前も固いし
意味わかんねえから
貝殻のclamを頑張ってもじって
クリームって名前にするくらいの
努力はあってよかった
- 277 ：
- >>275
そういう意味ではfunctionを名前ありの関数にもラムダにも使ったJavaScriptは上手いと思う
らむだ何ソレ？な人にも「関数名書かないで使うと無名の関数も作れるよ」って説明で事足りるもんね
- 278 ：
- ブロックとProc.newとprocとlambdaと->があるRubyはやり過ぎ
- 279 ：
- >>278
まあ、Rubyは他の組み込みライブラリでも
エイリアスや似たようなメソッド、所属モジュールが違う同様のメソッドとか持つのは普通だからね
俺は昔からproc派、RubyのProcとλ算法は別物だと思うからあの挙動でいいし、早く書けるし
- 280 ：
- >>270
>あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、
いや「あるかのよう」ではない、>>247 で以下のように、断定的に明記したとおり：
> まず >>240 で書いたように、Ruby の「ブロック付きメソッド呼び出し」は構文糖だ
Ruby インタブリタの内部では「ブロック付きメソッド呼び出し」と
「値渡しされた Proc オブジェクト」とは別の表現(C構造体)が用いられ、それらを相互変換している
ただし Ruby プログラマの視点では、値渡しされたProc オブジェクトで「あるかのように」
(すなわちファーストクラスとして)ブロックを扱う事ができる、だから「ブロックは構文糖」になる
ブロックを評価するのにメソッド Proc#call が必須(>>257)なのは、また別の理由....
それらをごっちゃにすべきではない
>>271
>まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら
いや「構文糖のような」という比喩表現であれば、何の問題も無い
>「真のクロージャ」って用語もおかしいのだと気付いて欲しいな
>>4 でクロージャ定義を示してから >>201 までソースを明かすのを遅らせたのは意図的だったけど、
「真のクロージャ」という曖昧な表現でいらぬ混乱を与えたことは余計だったと反省している
最初からストレートに「関数型言語のクロージャ」とすべきだったね
- 281 ：
- 関数型言語のクロージャと非関数型言語のクロージャはナニが違うですか。
- 282 ：
- 結局、Pythonのクロージャは本物で、Rubyのブロックは偽物って結論になったんか？
- 283 ：
- >>282
彼の中だけではそういうことらしい
- 284 ：
- 環境もちこしてる関数っぽいやつならクロージャでいいじゃん
- 285 ：
- って彼の中だけでは逆か
>>284
と言うか元々環境持ち越すのがクロージャの要件でしょ
- 286 ：
- なんで突っ込まれてるのかさっぱりわからん
- 287 ：
- >>286
突っ込んでないよ、超同意してんだよ
- 288 ：
- まじかよ世界は平和だった
- 289 ：
- >>281
もともとクロージャの概念/用語は関数型言語で生まれたものだから、
「非関数型言語のクロージャ」とは：
「関数型言語のクロージャ」の定義に対して、どれくらい忠実に実装されているか？
という相対的な評価になるね
- 290 ：
- そして、オリジナルのクロージャーが
一番優れているとかいう信者が現れるわけかｗ
普通はオリジナルを改良した方が
優れているんだがな。
- 291 ：
- >>282
でれでは、ここまでの結論をまとめてみる
まず最初は。>>289 の評価結果から：
[Python：X]
Python の lambda 構文は式しか書けないという制限があるから、
クロージャ固有の局所環境を持つことができない
したがって、Python の lambda 構文は「関数型言語のクロージャ」ではない
[Ruby：X]
Ruby のブロックはオブジェクトであるから、
その評価にはメソッド Proc#call をコールしなければならない
したがって、Ruby のブロックは「関数型言語のクロージャ」ではない
[JavaScript：O]
JavaScript の関数リテラルは任意の書けるからクロージャ固有の局所環境を持てるし、
なおかつ引数に適用するだけで評価できる
したがって、JavaScript の関数リテラルは「関数型言語のクロージャ」である
結果として、最も忠実に「関数型言語のクロージャ」が実装されている(>>277)、と言える
続けて、この評価結果が現実のプログラミングに与える影響をまとめる
ここでは Apple 公式リファレンスに含まれる Swift クロージャのサンプルコードを「お題」とした(>>191)
・高階関数 map に与えるクロージャをインラインで書ける
[Python：X]
・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>208)
・このため、一般には(インラインで書くのはあきらめて)関数定義を使わざるをえない
[Ruby & JavaScript：O]
・インラインで自然な while ループを使った(ふつうのプログラマにとって)分かりやすいコードが書ける
・参照透明性のある関数型プログラミングで書ける
[Python：X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>208)
[Ruby：O] (関数再帰の代わりに)組み込みの高階関数風メソッドを使うことで、可読性の高いコードが書ける(>>267)
[JavaScript：？] （書けるか否か、現時点では不明）
- 292 ：
- >>282 を一部訂正
X：JavaScript の関数リテラルは任意の書けるから
O：JavaScript の関数リテラルは任意の文が書けるから
- 293 ：
- >>291
再帰関数よりwhileループが読みやすいレベルの人間が
関数型プログラミングについて語るなんて滑稽すぎる
- 294 ：
- >>291
あと、>>208じゃなくて>>203を評価すべきだと思うんだけど、
なんでワザワザ可読性を落としてる方を評価してるの？
まさか、Rubyでinjectは使って良いけど、Pythonでapplyfは使っちゃダメとでも言うつもり？
- 295 ：
- 可読性の良し悪しなんて定量的ではないものを評価対象にするとか
- 296 ：
- > Python の lambda 構文は式しか書けないという制限があるから、
> クロージャ固有の局所環境を持つことができない
def make_f(n): return lambda x: x + n
f = make_f(1)
n = 1000
f(1) #=> 2
こういう風に、（引数以外の変数を）実行時の環境じゃなくて
自身が定義された環境で解決できればクロージャだよ。
この場合は変数nのことね。
- 297 ：
- >>289
レキシカルクロージャってSchemeが最初だと思うけど、
Schemeって純粋な関数型言語じゃないよね。
- 298 ：
- >>294
お題に対して「Python だけがわざわざ関数 applyf をユーザ定義しなければならない」ことを問題視している
>>203 のコードは「お題を(勝手に改変せず)インラインで書ける」という観点だと(評価以前に)失格だ
もしも Python コミュニティにおいて関数 applyf が常識的に認知されていたならば、
(map/filter/reduce 等と同様に) applyf は組み込み関数として実装されていたはず
なお、組込み関数の実装レベルは言語によって差異があるものだから、
公平性を考慮して functools のような標準ライブラリを import するのは認める
また Ruby のメソッド Enumerable#inject に対応する Python の関数は reduce だよ
Python で組込み関数 reduce を使うのは、まったく問題無い
- 299 ：
- ていうか、さらっと1個の式で書けないような処理はインラインに書こうとするなよ
っていうのがpythonの求めるところなんじゃないの？
- 300 ：
- >>203 はインラインでは書けていないけど、>>208 と比べれば可読性の高いコードであると思うから、
>>294 の主張を受け入れて >>291 を以下のように一部改訂する（＊ で始まる行を変更している）
改定前：
・高階関数 map に与えるクロージャをインラインで書ける
[Python：X]
・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>208)
＊ ・このため、一般には(インラインで書くのはあきらめて)関数定義を使わざるをえない
・参照透明性のある関数型プログラミングで書ける
＊ [Python：X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>208)
改訂後:
・高階関数 map に与えるクロージャをインラインで書ける
[Python：X]
・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>208)
＊ ・このため、一般には(インラインで書くのはあきらめて)関数定義または変数宣言(>>203)を使わざるをえない
・参照透明性のある関数型プログラミングで書ける
＊ [Python：X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>203,205)
- 301 ：
- むしろ標準で用意されてなくてもユーザ定義で拡張できるのは
言語として筋が良いといえる
- 302 ：
- 謎の標準ライブラリ縛りが入りましたw
- 303 ：
- 1個の式で済む以上の事をやろうとする処理に名前を付ける事が、なぜ可読性の低下につながるの？
- 304 ：
- 再帰は可読性低いって連呼しててワロタ
Rubyユーザって、ブロック使ってるだけで関数型だと思ってるの？
- 305 ：
- Schemeは普通ならループで済むような事まで再帰で書くぜ
- 306 ：
- 再帰よりnamed let使おう
- 307 ：
- named let は再帰でしょ？
- 308 ：
- 書いた後に思った
- 309 ：
- >>304
彼だけだよ
- 310 ：
- lispおじさんに言わせれば
全部lispのパクりだから
全部クロージャで問題ないよ
- 311 ：
- なんでクロージャスレでClojureを話題にしないの？
- 312 ：
- >>311
若いときは買ってでもするものなあ〜んだ？
- 313 ：
- >>312
ゲーム
- 314 ：
- ClosureCL…(ﾎﾞｿｯ
- 315 ：
- >>191
流れをナナメ読みかつ関数型言語素人なんだけど、
関数型言語だとそのアップルサイトの例はどういうふうに書くもんなの？
let digitNames = [0,"Zero"; 1,"One"; 2,"Two"; 3,"Three"; 4,"Four"; 5,"Five"; 6,"Six"; 7,"Seven"; 8,"Eight"; 9,"Nine"];;
let numbers = [16; 58; 510; 0];;
let strings = List.map (fun n ->
let rec f n acc =
match (n, n / 10) with
(0, 0) -> List.assoc 0 digitNames
| (_, 0) -> List.assoc (n mod 10) digitNames ^ acc
| (_, _) -> f (n / 10) (List.assoc (n mod 10) digitNames ^ acc)
in f n "") numbers;;
List.iter (fun s -> print_endline s) strings;;
言語はOCaml。三つの変数名はオリジナル版を採用。
dictionaryは諸事情でめんどいのでタプルのリストで代用。
関数型言語のことはまったくわからないｗ
- 316 ：
- >>312
SEX
- 317 ：
- >>315
Standard ML で素直に末尾再帰を使って書いてみた
http://ideone.com/WpChMC
- 318 ：
- >>317
おおっ！わざわざどうも！
SMLとOCamlの関係だからこういう似たような感じになるのかな？
それともループを再帰に置き換えたらどうせどの言語でもこんな感じかな？
それにしても関数型言語なるものを知るにつれて思うのは、
再帰についてはすがすがしいが、
それ以外についてはタイプ量が増えがちってこと。
ハッシュテーブルひとつ準備するのにもウダウダ。
関数型どうのというより、個別の言語によるのかもしれないけど…。
- 319 ：
- >>318
>SMLとOCamlの関係だからこういう似たような感じになるのかな？
SML も OCaml も同じML族の一員ですから、そんな感じになるのも不思議じゃないと思いますね
>それともループを再帰に置き換えたらどうせどの言語でもこんな感じかな？
SML 以外の関数型言語は触った程度のレベルなので、以下はあくまで私見です：
・Lisp でも似た感じの再帰になる
ただし Lisp は TCO が保証されていないから、一般的な反復処理であれば
loop や while マクロ(または、その相当品)で手続き的なループで書く
・Scheme は TCO が言語仕様で保証されているので、普通は再帰で書く(>>305)
また継続(call/cc)があるので、loop や while の相当品を関数として自前で定義することも可能
・Haskell の場合、初めのうちは(ML や Scheme と同様に)再帰で書く
ただし Haskell だと文字列は文字型のリストであり、標準ライブラリの unfoldl を使う事を学ぶようになる
・関数プログラミングの楽しみ
http://www.amazon.co.jp//dp/4274068056
第3章「おりがみプログラミング」で詳しく解説されています
ということで Haskell の定義を参考にして、SML でも関数 unfoldl で再帰を抽象化したコードを書きました：
http://ideone.com/o5JM86
ここで unfold とは、よく知られている fold の双対な概念です
（fold は、Ruby だと inject、Lisp や JavaScript では reduce と呼ばれています）
fold xs が「あるリスト xs を畳んだ値 y」を返すのに対し、
unfold y は「ある値 y を広げたリスト xs」を返します
なお、「畳む/広げる」という言葉よりも「分解する(destruct)/組立てる(construct)」のほうが直感的かもしれません
（＊ 長いので、続く ＊）
- 320 ：
- （＊ >>319 の続き ＊）
なお、map や filter といった高階関数を一般化したものが fold であることは
よく知られていますが、ここでリストを代数(群)に見立てた圏論の視点で再構成すると：
・fold を(更に)一般化したものがカタモルフィズム(catamorphism)である
・unfold を(更に)一般化したものがアナモルフィズム(anamorphism)である
という、本質的な形でリスト処理を定義できるようになります
(モナドとは関連しない)圏論を応用したプログラミングについては、以下のプレゼンがお薦めです
・Introduction to Categorical Programming (Revised)
http://www.slideshare.net/sakai/introduction-to-categorical-programming-revised
p.18 の図式を使った「圏論でのリスト型の定義」が直感的です
詳細については、以下の記事で紹介されている論文(英語)が分かりやすかったです
・Haskellと圏論を学んできて、そのまとめとしてちょうどよい論文を見つけたのでメモ。
https://plus.google.com/+OsamuNagano/posts/7cPfAQ145Yi
>それにしても関数型言語なるものを知るにつれて思うのは、....
ML や Haskell は静的型付けによる安全性と高速化を主眼に設計された言語ですから、
Ruby や Python といったスクリプト言語の置き換えには成り得ないと考えます
これに関しては、以前に別スレ「LLにおける関数型プログラミング」で説明しています
http://peace.2ch.sc/test/read.cgi/tech/1345123070/28
また ML や Haskell の強力な型推論は、データ型に関する矛盾(=バグ)が存在しないことを(実行の前に)証明しますが、
動かしては書き直す(いわゆるトライ＆エラー)が一般的なスクリプトプログラミングには不向きだと考えます
（＊ これで終わり ＊）
- 321 ：
- 長い
3行でまとめろ
- 322 ：
- 珍しく普通に相手にしてもらって
うれしくてたまらない
オレオレクロージャくんであった
- 323 ：
- >>319-320
> Lisp は TCO が保証されていないから
TCOが保証されての末尾再帰。何がすがすがしいって、これですよね。
これがあるから書いていける。
保証なしで気軽に再帰なんかしてもスタックオーバーフローでげんなりだし。
> Haskell だと文字列は文字型のリストであり、標準ライブラリの unfoldl を
おったまげですね。初めてunfoldなるもんを知りました。
Rubyでinject、OCamlでfold_left/fold_rightは馴染みがあったんですが。
何かHaskellって…グイグイ来てますよね！（小学生並みの感想）。
> cata, ana, 圏論, 圏論でのリスト型の定義
リンク先拝見しましたが現時点でどうも1ミリも理解できていません。半笑いです。
> http://ideone.com/o5JM86
ありがとうございます。よく考えると37行目の「 ^ output」が不要にも見えますね。
- 324 ：
- 源クロウジャ義経
- 325 ：
- >>322
分かりやすいですー
- 326 ：
- >>323
>よく考えると37行目の「 ^ output」が不要にも見えますね。
バグ指摘ありがとうございます、変数 output そのものが不要でした
対策を以下へ反映し、ついでに Ruby と Python でも unfold を使って書いてみました
・Standard ML
http://ideone.com/3L6yJ0
・Ruby
http://ideone.com/4OzC0s
・Python
http://ideone.com/8TouzI
>おったまげですね。初めてunfoldなるもんを知りました。
「unfold は fold の双対な概念」であることを知れば、応用範囲は広がります
今回は文字列の unfold でしたが、リスト/配列/辞書/集合/スタック/キューといった
「コレクション・オブジェクトにおける fold/unfold」を考えることから始めませう
- 327 ：
- TCO無くて正格評価なPythonでは
unfoldはループ&ジェネレータで実装した方が良いね
それと文字列に限定する意味って無いよね
http://ideone.com/e1fKAL
- 328 ：
- この話題クロージャとか特に関係なく、Pythonの無名関数には文を書けず式しか書けないという単純な事実の指摘でＯＫ？
関数型プログラミングのラムダとしては困らないが、手続き型言語における無名関数としては不便だろうな
自分はPythonを使わないので、Pythonでの「普通の」プログラミングスタイルがどっちなのかは知らん
- 329 ：
- Hackで適当に書いてみたら本体は一行だった。PHPの緩さにラムダ加わるの最強
$strings = array_map($n ==> array_reduce(str_split($n), ($s, $d) ==> $s . $digitNames[$d]), $numbers);
- 330 ：
- そんなので良ければPythonでも一行
strings = [''.join(digitNames[x] for x in str(n)) for n in numbers]
- 331 ：
- あれ、それdigitNames[x]のxに文字列で渡ると思うけど、Pythonも勝手に数値に変換してくれるんだっけ？
整数に変換してやらないと駄目な記憶があっていちいち面倒くさいと思ってた
- 332 ：
- digitnames = { "0": "Zero" ... } なら>>331
digitnames = { 0: "Zero" ... } なら digitNames[int(x)]になるだけだろ。
Perlなら
my @string = map{ join '', @digit_names{split //, $_} } @numbers;
Javascriptなら
var strings = numbers.map(function(number) {
return number.toString().split("").map(function(x) { return digitNames[x] }).join("");
});
Javascriptはアロー演算子が欲しいところだ。
- 333 ：
- 最強言ったから気に食わなかったならスマンカッタ
PHPの緩さは、こういうのが動くところ。>>329でそのまま動く
$digitNames = ['Zero','One','Two','Three','Four','Five','Six','Seven','Eight','Nine','.'=>'Point','-'=>'Minus'];
$numbers = [1.234, -5.4321];
- 334 ：
- >>327
>>326 と比較すると：
・わざわざジェネレータで「組立てた」シーケンスを
reduce で「畳み込んで」いて、二重のループになっているから処理効率(=性能)が悪く、
なおかつ reduce へ渡すラムダ式が増えているからコードも複雑化してしまっている
・そもそも「Haskell の unfold 定義」に従って関数定義していないから
その関数の命名 unfold は不適切であり、別の名前を考案すべき
念の為に「Haskell の unfold 定義」を以下に示す（ただし末尾再帰ではなく一般再帰）：
unfold :: (B -> Maybe (A, B)) -> B -> [A]
unfold f u = case f u of
Nothing -> []
Just (x, v) -> x : (unfold f v)
この「Haskell の unfold 定義」に従った unfold の Python 実装を以下に書いた：
http://ideone.com/vpTBlR
・__unfoldl_string_rec__：一般再帰による実装（>>326 と同じ）
・__unfoldl_string_while__：while 文と破壊的代入を使った手続き型実装
あわせて Ruby の実装コードも更新した：
http://ideone.com/9x6s0h
コードの要点を示す：
・Python のジェネレータを Ruby では外部イテレータ Enumerator と呼ぶが、
(Ruby 1.9 以降のメソッド定義マナーに従い)ブロックが渡されていない場合には
(組込みメソッド Object#to_enum を使って)外部イテレータを返すようにした
・３種類のメソッド定義を示した
・String#__unfoldl_rec__：一般再帰による実装（>>326 と同じ）
・String#__unfoldl_until__：until 文と破壊的代入を使った手続き型実装
・String#__unfoldl_loop__：メソッド loop を使った参照透明性のある関数型実装（>>267）
最後に、Ruby と同様な「Haskell の unfold 定義」に従った
Python のジェネレータ実装については、>>327 への宿題としておく
（ML や Haskell といった静的型付け関数型言語に慣れていないと、難しいかもしれないが....）
- 335 ：
- Pythonの場合リストを返したかったら list(unfold(f, x)) で良くね？
毎回 s += a 等やって組み立てるよりも速いぞ
- 336 ：
- あ、もしかしてunfoldlじゃないからダメって言ってんの？
unfoldには unfoldr と unfoldl の二種類あって、HaskellではPreludeにあるのはunfoldrだけだぞ
- 337 ：
- ちなみに>>334が自信満々に貼ってる方のHaskellのunfoldの定義はunfoldrの方なw
- 338 ：
- unfold :: (B -> Maybe (A, B)) -> B -> [A]
じゃないから駄目とか言っといて、なんで出してる実装はことごとく
unfold :: (B -> Maybe (A, B)) -> B -> A
なの？ バカなの？
- 339 ：
- またオレオレ定義君がやらかしちゃったかー
- 340 ：
- cにクロージャくれよっておもってたけど
今ならgoがあるんだよな
- 341 ：
- C++使ったら？スコープ抜けた際どうなるか、必要ならコピーを持たせよう、とかスマポにするかーとか、考える必要はあるけど
- 342 ：
- >>340
clangならblocksが使えるんじゃないかしら
- 343 ：
- ほー objc じゃなくても使えるのか。
まあ objc に c のソースだけ食わせて使ってもいいんだけど。
- 344 ：
- boost lambdaで怖い思いしたから
c++はng
コンパイルエラーから黒魔術なコード出されてもこまる
- 345 ：
- そういうのはreplで対話的に書けたほうがいいな
- 346 ：
- このスレのおかげでクロージャの良さと
Ruby信者のキモさが分かりました
ありがとうございました
- 347 ：
- クロージャなんて最近の言語は大抵あるからね
次に関数型言語からパクって欲しいのはパターンマッチ
- 348 ：
- disると公開される
- 349 ：
- まぁ別にいらないっちゃいらないな。
最近の言語はいろいろ付けすぎだわ。
もっと仕様単純でいいよ。
- 350 ：
- パターンマッチの無い言語にパターンマッチを付けられるような言語がいい
- 351 ：
- >>350
プリプロセッサを使えば、どんな言語でも
なんだって出来るんじゃね？
- 352 ：
- その万能プリプロセッサがあればいいんだけど
- 353 ：
- m4通すとか？
- 354 ：
- その言語処理系を書かた言語のコードを直接書き変えるような書き方じゃなくて
その言語自体で新しい表現(パターンマッチとか)を定義出来るようにするってこと
- 355 ：
- >>350
lispおじさんだ！
- 356 ：
- lispでマクロ使えばおk
- 357 ：
- >>354
たぶんschemeにドハマリするタイプ
- 358 ：
- on lispとかlet over lambdaがあるcommon lispの方がいいんじゃね
- 359 ：
- あなほりマクロ怖い
- 360 ：
- やっぱりpythonとかhaskellのコードと比べると
専用の構文があった方がスッキリ書ける
でもそうすると自由度が無くなってマクロがうまく使えないジレンマ
- 361 ：
- 一応リーダマクロを使えば解決するんだけど結局使わなくなる
- 362 ：
- lispおじさんのせいで
すっかりマクロ談義スレになったな
- 363 ：
- 真のクロージャとマクロ、どっちがマシか難しいところだな
- 364 ：
- 二つのいいところを組み合わせたものが最強ではないだろうか？
つまりマクロージャー
- 365 ：
- マクロにコンテクストが付いて回るclの事だよねそれ
- 366 ：
- マクロとクロージャを組み合わせればOOPも継続も後から付けられる
- 367 ：
- いろんなことができる。そうマクロージャならね！
- 368 ：
- >>366
継続渡しではないですよね？
マクロとクロージャーで継続をどう実装するか
ぱっとは思いつかなかったのでよかったら教えてください。
- 369 ：
- onlispでは継続を表わすクロージャを引数で渡してそれをマクロで包んでる
これだと使う側が末尾呼出的に書かないといけない縛りがある
cl-contは式をwithマクロで包んでその式をcodewalkしてcps変換してる
- 370 ：
- ありがとうございます。On Lisp 読んでみます。
- 371 ：
- そもそも関数が一級オブジェクトである必要があるのかどうか疑問が出てきました
ifelse( aaa, xxx,
ifelse( bbb, yyy,
ifelse( ccc, zzz,
iii )))
↑R
IDE使えってことなんでしょうけど認知に負荷をかける言語仕様は間違ってると思うんですよね
これよりはメソッドチェーンの方がかなりスマートだと思う
foo(aaa){xxx}.bar(bbb){yyyy}.baz(ccc){zzz}
- 372 ：
- それだと全てのメソッドで条件分岐を想定した実装にしなくちゃいけなくなるのでは
- 373 ：
- Pythonはパターンマッチ以前にSwichtすらない
- 374 ：
- >>373
そんなもんがある言語を見たことないが
- 375 ：
- なんかドイツ語？みたいな切り方だな
- 376 ：
- ゲルマンおじさんこわい！
- 377 ：
- スウィヒトとか読むの？ドイツ語ってよくわからんタイミングで濁るイメージあ？からジットとかかな
- 378 ：
- スヴィヒトだな、あえてカタカナを当てれば
- 379 ：
- 中二病みたい
- 380 ：
- ここまでnonlocalなし
- 381 ：
- 関数を返す関数を定義するときにはいる
- 382 ：
- Objective-Cのblocksが便利だというからいろいろ読んでみたが
使い道がよーわからん。他言語のクロージャやラムダだということで
他言語のクロージャやラムダについて読んでたらもっと混迷が深まった。
- 383 ：
- サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート
- 384 ：
- 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
い
- 385 ：
- 保守
- 386 ：
- S8R
- 387 ：
- 関数型で参照透過性とか言ってるのに
クロージャにしたら意味ないじゃん。
やっぱりオブジェクト指向のほうが優れてるの？
- 388 ：
- ラムダ式はともかくクロージャなんて純粋な関数型では使わないだろう
- 389 ：
- 関数型ではクロージャーは当たり前
というより関数とクロージャーに意味論的な違いはない
特定のパターンの書き方の関数をそう呼んでるだけ
- 390 ：
- >>389
ラムダ式と混同してる？
- 391 ：
- >>390
混同もなにも根元的にすべてがラムダ項なのが関数型だろ
ひょっとして匿名関数をラムダと呼んでるニワカ？
- 392 ：
- クロージャとラムダを混同してないかって事じゃね？
- 393 ：
- なんでじゃねじゃね言い合うのか
なぜ本人同士が出てきてやりあわないのか
- 394 ：
- >>392
> クロージャとラムダを混同してないかって事じゃね？
そう読解した上での >>391 だっての
お前も表層的なsyntaxしか理解してないくちだな
- 395 ：
- お前はさながらコミュ症と称されるくちだなｗ
- 396 ：
- これはひどい
- 397 ：2018/08/23
- 苦労じゃー
ら無駄
Pythonについて（アンチ専用）
画像処理 15枚目
ほぼ初心者プログラマでするべき事がわからない
Visual Studio Code / VSCode Part3
【えっ】Perlに未来はあるのか？【終わり？】
マルチスレッドプログラミング相談室 その9
ネットワークプログラミング雑談
ハッシュ使うのやめてクラスにしましょう
本当に必要ものは人工知能ではなくて検索エンジン
WPF(.NET4.x, .NET Core) GUIプログラミング Part23
--------------------
【回顧】乙女新党 Part.19【新情報】
簡単ドリップ専用スレ
【TV】水曜日のダウンタウン、やらせ疑惑浮上
地球少女アルジュナ
【BlackDesert】黒い砂漠 キャラクリスレPart6
【薬漬け】製薬会社の工場で働いてる人 語れ！
草津温泉 Part13
【107期】鈴木竜士（茨城)【復刻版】
草津温泉 Part27
ドケチなら図書館愛用するよな？ 9館目
がんばれマカフィー Part96 / McAfee
【日暮里】一由そば 10杯目【店主復帰祈願】
【19卒】なんJ就職部
結婚反対されてからの婚約破棄
【SKE48卒業生】松井玲奈 応援スレ☆958.1【(れ・ω・な)】
【ガセ厳禁】地方局飛び乗り・飛び降り Part102
【89式】戦後国産小火器総合 41【64式】
【光通信】BroadAceどうよ【系列】
庭球ヲチ5
【IU】アイユ応援スレ☆17【日本人専用】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
