クロージャって何がいいの？

1 ：デフォルトの名無しさん：2014/11/08(土) 13:11:47.84 ID:6V2MLUHb.net

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

2 ：デフォルトの名無しさん：2014/11/08(土) 13:17:58.06 ID:rszc5DFq.net

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

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

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

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

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

3 ：デフォルトの名無しさん：2014/11/08(土) 13:42:47.14 ID:alIlcZLx.net

ディスクロージャ

4 ：デフォルトの名無しさん：2014/11/08(土) 14:33:50.79 ID:Wb7Sa5AG.net

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

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

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

5 ：デフォルトの名無しさん：2014/11/08(土) 16:17:08.12 ID:gNjtEENQ.net

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

6 ：デフォルトの名無しさん：2014/11/08(土) 16:19:08.12 ID:gwropNof.net

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

7 ：デフォルトの名無しさん：2014/11/08(土) 16:28:06.78 ID:Z0nNiFel.net

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

8 ：デフォルトの名無しさん：2014/11/08(土) 18:29:54.75 ID:+pW0VlFs.net

>>1
匿名クラスは嫌。

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

9 ：デフォルトの名無しさん：2014/11/08(土) 18:31:45.04 ID:Z0nNiFel.net

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

10 ：デフォルトの名無しさん：2014/11/08(土) 21:41:30.87 ID:1bx+kI6Q.net

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

11 ：デフォルトの名無しさん：2014/11/08(土) 22:16:16.20 ID:BzSpEdoH.net

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

12 ：デフォルトの名無しさん：2014/11/09(日) 01:25:23.88 ID:5LKfT6rZ.net

まじすか

13 ：デフォルトの名無しさん：2014/11/09(日) 02:04:06.76 ID:8LiWtrih.net

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

14 ：デフォルトの名無しさん：2014/11/09(日) 03:36:21.74 ID:Rov3GL+Ot

A{B{C}} というスコープがあるとき、一般的には、
C→Bのように、内から外はアクセスできるが、
A→Bのように、外から内はアクセスできない

ここで、Aからクロージャで、Bの内部関数Cを返すと、
Cは自分の外部環境Bを保持しており、
CからBをアクセスできるので、その結果、
AからBの環境にもアクセスできる

15 ：デフォルトの名無しさん：2014/11/09(日) 05:57:17.96 ID:n2NDOrh4.net

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

16 ：デフォルトの名無しさん：2014/11/09(日) 07:54:16.27 ID:6VpE/OBT.net

lispの方言かとおもった

17 ：デフォルトの名無しさん：2014/11/09(日) 09:19:55.73 ID:nlmXbEn2.net

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

18 ：デフォルトの名無しさん：2014/11/09(日) 10:23:47.55 ID:gYZvrVR/.net

>>11
複数にできるよ

19 ：デフォルトの名無しさん：2014/11/09(日) 16:16:30.86 ID:K4BO8Ja1.net

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

20 ：デフォルトの名無しさん：2014/11/09(日) 16:48:40.28 ID:EbU/SVlS.net

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

21 ：デフォルトの名無しさん：2014/11/09(日) 17:24:14.45 ID:xhtawW2X.net

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

22 ：デフォルトの名無しさん：2014/11/09(日) 17:32:09.95 ID:PiaxZAwM.net

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

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

23 ：デフォルトの名無しさん：2014/11/09(日) 17:38:41.70 ID:50xVLBic.net

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

24 ：デフォルトの名無しさん：2014/11/09(日) 18:18:41.40 ID:K4BO8Ja1.net

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

25 ：デフォルトの名無しさん：2014/11/09(日) 18:20:47.86 ID:xhtawW2X.net

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

26 ：デフォルトの名無しさん：2014/11/09(日) 18:24:28.78 ID:KOr7L+hP.net

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

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

27 ：デフォルトの名無しさん：2014/11/09(日) 18:40:07.36 ID:lx9et4kr.net

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

28 ：デフォルトの名無しさん：2014/11/09(日) 18:40:57.06 ID:nlmXbEn2.net

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

29 ：デフォルトの名無しさん：2014/11/09(日) 18:55:58.44 ID:KOr7L+hP.net

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

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

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

30 ：デフォルトの名無しさん：2014/11/09(日) 18:59:22.34 ID:KOr7L+hP.net

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

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

31 ：デフォルトの名無しさん：2014/11/09(日) 19:03:23.62 ID:lx9et4kr.net

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

32 ：デフォルトの名無しさん：2014/11/09(日) 19:08:15.30 ID:nlmXbEn2.net

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

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

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

33 ：デフォルトの名無しさん：2014/11/09(日) 19:13:25.68 ID:nlmXbEn2.net

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

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

34 ：デフォルトの名無しさん：2014/11/09(日) 19:19:20.49 ID:5LKfT6rZ.net

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

35 ：デフォルトの名無しさん：2014/11/09(日) 19:22:02.17 ID:lx9et4kr.net

見えるよ

36 ：デフォルトの名無しさん：2014/11/09(日) 19:25:16.21 ID:5LKfT6rZ.net

そうだよね...

37 ：デフォルトの名無しさん：2014/11/09(日) 19:39:55.45 ID:KOr7L+hP.net

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

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


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

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

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

38 ：デフォルトの名無しさん：2014/11/09(日) 19:44:13.19 ID:5LKfT6rZ.net

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

39 ：デフォルトの名無しさん：2014/11/09(日) 19:44:17.88 ID:KOr7L+hP.net

>>34
もちろん見えるよ

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

40 ：デフォルトの名無しさん：2014/11/09(日) 19:47:57.23 ID:nlmXbEn2.net

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

やり直し

41 ：デフォルトの名無しさん：2014/11/09(日) 19:48:24.99 ID:5LKfT6rZ.net

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

42 ：デフォルトの名無しさん：2014/11/09(日) 20:00:59.51 ID:lx9et4kr.net

>>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 ：デフォルトの名無しさん：2014/11/09(日) 20:10:51.52 ID:KOr7L+hP.net

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

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

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

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

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

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

44 ：デフォルトの名無しさん：2014/11/09(日) 20:14:38.63 ID:nlmXbEn2.net

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

45 ：デフォルトの名無しさん：2014/11/09(日) 20:19:48.73 ID:5LKfT6rZ.net

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

46 ：デフォルトの名無しさん：2014/11/09(日) 20:27:21.21 ID:5LKfT6rZ.net

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

47 ：デフォルトの名無しさん：2014/11/09(日) 20:32:25.05 ID:lx9et4kr.net

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

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

48 ：デフォルトの名無しさん：2014/11/09(日) 20:34:00.52 ID:KOr7L+hP.net

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

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

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

49 ：デフォルトの名無しさん：2014/11/09(日) 20:34:54.87 ID:nlmXbEn2.net

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

50 ：デフォルトの名無しさん：2014/11/09(日) 20:37:14.94 ID:nlmXbEn2.net

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

51 ：デフォルトの名無しさん：2014/11/09(日) 20:40:33.21 ID:lx9et4kr.net

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

52 ：デフォルトの名無しさん：2014/11/09(日) 20:49:43.56 ID:lx9et4kr.net

>>45
そうだよ

53 ：デフォルトの名無しさん：2014/11/09(日) 21:05:06.25 ID:KOr7L+hP.net

>>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 ：デフォルトの名無しさん：2014/11/09(日) 21:08:04.55 ID:lx9et4kr.net

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

関数型とは一体…

55 ：デフォルトの名無しさん：2014/11/09(日) 21:09:53.89 ID:5LKfT6rZ.net

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

56 ：デフォルトの名無しさん：2014/11/09(日) 21:12:20.49 ID:lx9et4kr.net

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


これが参照透過性です

57 ：デフォルトの名無しさん：2014/11/09(日) 21:14:02.40 ID:KOr7L+hP.net

（>>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 ：デフォルトの名無しさん：2014/11/09(日) 21:18:46.76 ID:KOr7L+hP.net

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

添削しよう：

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

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

59 ：デフォルトの名無しさん：2014/11/09(日) 21:25:01.25 ID:KOr7L+hP.net

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

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

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

60 ：デフォルトの名無しさん：2014/11/09(日) 21:31:21.14 ID:lx9et4kr.net

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

61 ：デフォルトの名無しさん：2014/11/09(日) 21:36:16.07 ID:lx9et4kr.net

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

62 ：デフォルトの名無しさん：2014/11/09(日) 21:41:46.54 ID:LUEi6lWE.net

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

63 ：デフォルトの名無しさん：2014/11/09(日) 21:44:14.34 ID:KOr7L+hP.net

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

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

64 ：デフォルトの名無しさん：2014/11/09(日) 21:45:18.38 ID:lx9et4kr.net

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

65 ：デフォルトの名無しさん：2014/11/09(日) 21:49:19.33 ID:lx9et4kr.net

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

66 ：デフォルトの名無しさん：2014/11/09(日) 21:50:58.85 ID:KOr7L+hP.net

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

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

67 ：デフォルトの名無しさん：2014/11/09(日) 21:55:24.38 ID:lx9et4kr.net

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

68 ：デフォルトの名無しさん：2014/11/09(日) 21:58:19.30 ID:KOr7L+hP.net

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

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

69 ：デフォルトの名無しさん：2014/11/09(日) 22:04:34.10 ID:lx9et4kr.net

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

70 ：デフォルトの名無しさん：2014/11/09(日) 22:05:03.57 ID:TZMLlS/6.net

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

71 ：デフォルトの名無しさん：2014/11/09(日) 22:10:31.90 ID:KOr7L+hP.net

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

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

72 ：デフォルトの名無しさん：2014/11/09(日) 22:13:13.99 ID:n2NDOrh4.net

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

73 ：デフォルトの名無しさん：2014/11/09(日) 22:21:17.10 ID:KOr7L+hP.net

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

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

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

74 ：デフォルトの名無しさん：2014/11/09(日) 22:21:52.15 ID:lx9et4kr.net

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


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

75 ：デフォルトの名無しさん：2014/11/09(日) 22:25:17.72 ID:lx9et4kr.net

>>68
そっちが言う馬鹿(>>73)がいたよ



まさかの同一ID⁉︎

76 ：デフォルトの名無しさん：2014/11/09(日) 22:28:55.78 ID:GwhuA7Og.net

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

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

77 ：デフォルトの名無しさん：2014/11/09(日) 22:31:31.78 ID:KOr7L+hP.net

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

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

78 ：デフォルトの名無しさん：2014/11/09(日) 22:45:45.31 ID:KOr7L+hP.net

>>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 ：デフォルトの名無しさん：2014/11/09(日) 22:46:49.16 ID:nlmXbEn2.net

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

80 ：デフォルトの名無しさん：2014/11/09(日) 22:49:23.73 ID:5LKfT6rZ.net

>>78
>>45

81 ：デフォルトの名無しさん：2014/11/09(日) 22:51:44.34 ID:lx9et4kr.net

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

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

82 ：デフォルトの名無しさん：2014/11/09(日) 22:54:09.40 ID:nlmXbEn2.net

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

83 ：デフォルトの名無しさん：2014/11/09(日) 22:56:01.93 ID:5LKfT6rZ.net

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

84 ：デフォルトの名無しさん：2014/11/09(日) 22:56:21.23 ID:KOr7L+hP.net

>>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 ：デフォルトの名無しさん：2014/11/09(日) 22:59:47.88 ID:QKkGL4h0.net

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

86 ：デフォルトの名無しさん：2014/11/09(日) 23:01:05.93 ID:lx9et4kr.net

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

87 ：デフォルトの名無しさん：2014/11/09(日) 23:08:28.24 ID:KOr7L+hP.net

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

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

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

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

88 ：デフォルトの名無しさん：2014/11/09(日) 23:13:26.40 ID:5LKfT6rZ.net

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

89 ：デフォルトの名無しさん：2014/11/09(日) 23:16:00.89 ID:KOr7L+hP.net

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

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

90 ：デフォルトの名無しさん：2014/11/09(日) 23:18:21.66 ID:G8K4RNhm.net

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

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

91 ：デフォルトの名無しさん：2014/11/09(日) 23:18:59.88 ID:nlmXbEn2.net

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

92 ：デフォルトの名無しさん：2014/11/09(日) 23:23:03.86 ID:lx9et4kr.net

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

93 ：デフォルトの名無しさん：2014/11/09(日) 23:26:01.65 ID:lx9et4kr.net

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

94 ：デフォルトの名無しさん：2014/11/09(日) 23:27:54.79 ID:KOr7L+hP.net

>>91
>>89で書いたのは >>42 のラムダ式だけで書かれた Python コードだ
失礼した

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

95 ：デフォルトの名無しさん：2014/11/09(日) 23:30:45.91 ID:nlmXbEn2.net

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

96 ：デフォルトの名無しさん：2014/11/09(日) 23:33:02.09 ID:KOr7L+hP.net

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

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

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

97 ：デフォルトの名無しさん：2014/11/09(日) 23:33:22.37 ID:5KptUVSU.net

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

98 ：デフォルトの名無しさん：2014/11/09(日) 23:33:25.09 ID:5LKfT6rZ.net

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

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

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

99 ：デフォルトの名無しさん：2014/11/09(日) 23:36:58.94 ID:lx9et4kr.net

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

100 ：デフォルトの名無しさん：2014/11/09(日) 23:39:26.26 ID:nlmXbEn2.net

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

101 ：デフォルトの名無しさん：2014/11/09(日) 23:40:53.08 ID:KOr7L+hP.net

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

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

102 ：デフォルトの名無しさん：2014/11/09(日) 23:42:02.22 ID:nlmXbEn2.net

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

103 ：デフォルトの名無しさん：2014/11/09(日) 23:57:43.62 ID:KOr7L+hP.net

>>99
No だね

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

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

104 ：デフォルトの名無しさん：2014/11/09(日) 23:59:39.38 ID:yjLcynWs.net

話をまとめよう

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

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

105 ：デフォルトの名無しさん：2014/11/10(月) 00:08:24.74 ID:LMH7nFF4.net

>>104
添削してあげよう


--
話をまとめよう

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

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

106 ：デフォルトの名無しさん：2014/11/10(月) 00:14:31.96 ID:cCGgoLPL.net

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

107 ：デフォルトの名無しさん：2014/11/10(月) 00:28:52.73 ID:LMH7nFF4.net

>>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 ：デフォルトの名無しさん：2014/11/10(月) 00:37:52.21 ID:cCGgoLPL.net

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

109 ：デフォルトの名無しさん：2014/11/10(月) 00:42:53.31 ID:zIX5GD/A.net

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

110 ：デフォルトの名無しさん：2014/11/10(月) 01:06:17.40 ID:s5NqatD+P

だね。Python使いはlambdaが互換性のためだけに残ってる欠陥品って認識あるから
デモとかどうしても1行で書きたいときしか使わんけど、
シンタックスシュガーの実体がlambdaな方面からするとそんな事情しらんしキモいかもね。
defで名前付きで書くのがふつうだし機能上困ってない。

111 ：デフォルトの名無しさん：2014/11/10(月) 02:52:22.03 ID:qQmxJFhq.net

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

112 ：デフォルトの名無しさん：2014/11/10(月) 06:04:53.17 ID:i3Y7RgoA.net

馬鹿には無理

113 ：デフォルトの名無しさん：2014/11/10(月) 07:14:42.95 ID:0mRy26rG.net

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

114 ：デフォルトの名無しさん：2014/11/10(月) 08:48:39.72 ID:PWSP4TjP.net

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

115 ：デフォルトの名無しさん：2014/11/10(月) 09:04:03.39 ID:HTkQymog.net

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

116 ：デフォルトの名無しさん：2014/11/10(月) 10:20:30.55 ID:CeTPRNSr.net

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

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

117 ：1：2014/11/10(月) 11:39:28.98 ID:rdbd3Lyi.net

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

118 ：デフォルトの名無しさん：2014/11/10(月) 20:33:09.35 ID:AR7BQCkT.net

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

119 ：デフォルトの名無しさん：2014/11/10(月) 20:39:42.07 ID:5eyjbk6/.net

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

120 ：デフォルトの名無しさん：2014/11/10(月) 21:34:09.37 ID:Xzn5T3EF.net

>>117

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

121 ：デフォルトの名無しさん：2014/11/10(月) 22:47:25.14 ID:oQ75X8QG.net

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

122 ：デフォルトの名無しさん：2014/11/11(火) 06:32:45.68 ID:G8l0apNf.net

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

123 ：118：2014/11/11(火) 21:00:28.44 ID:UknPa1bY.net

レスお願いします

124 ：デフォルトの名無しさん：2014/11/11(火) 22:06:02.40 ID:3gT2I0NB.net

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

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

125 ：デフォルトの名無しさん：2014/11/12(水) 01:25:01.41 ID:G1/eYMX4.net

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

126 ：デフォルトの名無しさん：2014/11/12(水) 07:27:28.43 ID:ptlTHlgg.net

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

消費MP 5

127 ：デフォルトの名無しさん：2014/11/12(水) 08:10:30.04 ID:G1/eYMX4.net

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

128 ：デフォルトの名無しさん：2014/11/12(水) 08:13:15.39 ID:/hly7+iy.net

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

129 ：デフォルトの名無しさん：2014/11/12(水) 08:27:11.27 ID:cKuXIrT/.net

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

130 ：デフォルトの名無しさん：2014/11/12(水) 20:27:05.24 ID:3VJGATlA.net

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

131 ：デフォルトの名無しさん：2014/11/12(水) 20:37:53.49 ID:L8labB6g.net

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

132 ：デフォルトの名無しさん：2014/11/12(水) 20:38:24.71 ID:5GyhUZuz.net

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

133 ：デフォルトの名無しさん：2014/11/12(水) 20:52:00.80 ID:UPi6O5bX.net

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

134 ：デフォルトの名無しさん：2014/11/12(水) 21:14:25.68 ID:ptlTHlgg.net

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

消費MP 12

135 ：デフォルトの名無しさん：2014/11/12(水) 21:16:45.87 ID:eep146vT.net

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

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

136 ：デフォルトの名無しさん：2014/11/12(水) 21:23:36.45 ID:G1/eYMX4.net

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

137 ：デフォルトの名無しさん：2014/11/12(水) 21:36:55.56 ID:ptlTHlgg.net

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

138 ：デフォルトの名無しさん：2014/11/12(水) 21:59:20.14 ID:G1/eYMX4.net

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

139 ：デフォルトの名無しさん：2014/11/12(水) 22:58:17.02 ID:L8labB6g.net

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

140 ：デフォルトの名無しさん：2014/11/15(土) 12:17:49.98 ID:uUcubJGq.net

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

141 ：デフォルトの名無しさん：2014/11/15(土) 12:25:31.04 ID:u4ZMuG60.net

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

142 ：デフォルトの名無しさん：2014/11/15(土) 12:56:58.32 ID:XlhMXrhL.net

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

143 ：デフォルトの名無しさん：2014/11/15(土) 14:40:16.71 ID:EFct/v5k.net

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

144 ：デフォルトの名無しさん：2014/11/15(土) 14:43:26.00 ID:XlhMXrhL.net

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

145 ：デフォルトの名無しさん：2014/11/15(土) 15:14:55.72 ID:EFct/v5k.net

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

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


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

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

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

146 ：デフォルトの名無しさん：2014/11/15(土) 15:54:48.49 ID:uUcubJGq.net

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

147 ：デフォルトの名無しさん：2014/11/15(土) 15:58:46.71 ID:EFct/v5k.net

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

148 ：デフォルトの名無しさん：2014/11/15(土) 23:46:47.75 ID:JsFAZjCZ.net

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

149 ：デフォルトの名無しさん：2014/11/16(日) 10:37:06.14 ID:ZMiOBdAw.net

じゃあこれは？

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

150 ：デフォルトの名無しさん：2014/11/16(日) 11:54:54.13 ID:fx2XWh+X.net

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

151 ：デフォルトの名無しさん：2014/11/18(火) 16:33:41.48 ID:cuxiU0eb.net

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

152 ：デフォルトの名無しさん：2014/11/19(水) 22:27:12.37 ID:eeZRz+g3.net

>>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 ：デフォルトの名無しさん：2014/11/19(水) 23:00:05.80 ID:074lLX1H.net

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

154 ：デフォルトの名無しさん：2014/11/19(水) 23:12:18.42 ID:3WdraWBV.net

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

155 ：デフォルトの名無しさん：2014/11/19(水) 23:33:41.68 ID:PA9iCB5s.net

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

156 ：デフォルトの名無しさん：2014/11/19(水) 23:39:01.13 ID:QzanlTyB.net

>>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 ：デフォルトの名無しさん：2014/11/19(水) 23:57:41.67 ID:eeZRz+g3.net

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

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

158 ：デフォルトの名無しさん：2014/11/20(木) 00:02:30.91 ID:fhZ8V3Hu.net

>>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 ：デフォルトの名無しさん：2014/11/20(木) 00:19:03.39 ID:wJ3BgpRF.net

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

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

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

それとも、書けるかな？

160 ：デフォルトの名無しさん：2014/11/20(木) 00:20:15.54 ID:7GcQ+ika.net

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

161 ：デフォルトの名無しさん：2014/11/20(木) 00:29:37.23 ID:wJ3BgpRF.net

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

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

162 ：デフォルトの名無しさん：2014/11/20(木) 00:36:40.77 ID:ri7Qzvfi.net

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

163 ：デフォルトの名無しさん：2014/11/20(木) 00:37:00.07 ID:7GcQ+ika.net

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

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

164 ：デフォルトの名無しさん：2014/11/20(木) 00:42:39.12 ID:wJ3BgpRF.net

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

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

が返すのも同じ

165 ：デフォルトの名無しさん：2014/11/20(木) 00:44:55.24 ID:7GcQ+ika.net

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

166 ：デフォルトの名無しさん：2014/11/20(木) 00:45:40.70 ID:ri7Qzvfi.net

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

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

167 ：デフォルトの名無しさん：2014/11/20(木) 00:47:27.27 ID:wJ3BgpRF.net

>>165
>>105

168 ：デフォルトの名無しさん：2014/11/20(木) 00:52:13.60 ID:7GcQ+ika.net

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

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

169 ：デフォルトの名無しさん：2014/11/20(木) 00:58:03.79 ID:wJ3BgpRF.net

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

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

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

170 ：デフォルトの名無しさん：2014/11/20(木) 01:00:19.64 ID:fhZ8V3Hu.net

今の議論と全然関係ないんだけど、久しぶりに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 ：デフォルトの名無しさん：2014/11/20(木) 01:03:38.95 ID:ri7Qzvfi.net

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

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

172 ：デフォルトの名無しさん：2014/11/20(木) 01:04:53.19 ID:wJ3BgpRF.net

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

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

173 ：デフォルトの名無しさん：2014/11/20(木) 01:06:05.89 ID:7GcQ+ika.net

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

174 ：デフォルトの名無しさん：2014/11/20(木) 01:07:50.18 ID:fhZ8V3Hu.net

>>172
> >>32 をよく読み直そうね

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

175 ：デフォルトの名無しさん：2014/11/20(木) 01:10:58.55 ID:wJ3BgpRF.net

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

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

176 ：デフォルトの名無しさん：2014/11/20(木) 01:11:10.32 ID:7GcQ+ika.net

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

177 ：デフォルトの名無しさん：2014/11/20(木) 01:15:12.19 ID:wJ3BgpRF.net

>>173
クロージャだね

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

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

178 ：デフォルトの名無しさん：2014/11/20(木) 01:18:52.68 ID:7GcQ+ika.net

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

179 ：デフォルトの名無しさん：2014/11/20(木) 01:18:56.43 ID:fhZ8V3Hu.net

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

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

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

180 ：デフォルトの名無しさん：2014/11/20(木) 01:28:21.39 ID:wJ3BgpRF.net

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

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

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

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

181 ：デフォルトの名無しさん：2014/11/20(木) 01:32:42.88 ID:fhZ8V3Hu.net

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

182 ：デフォルトの名無しさん：2014/11/20(木) 09:44:37.50 ID:BfhGUngW.net

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

183 ：デフォルトの名無しさん：2014/11/20(木) 11:08:08.37 ID:nwROesTX.net

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

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

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

184 ：デフォルトの名無しさん：2014/11/20(木) 12:57:07.44 ID:5gFBGGbj.net

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

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

185 ：デフォルトの名無しさん：2014/11/20(木) 15:15:51.24 ID:W3M4RtQD.net

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

186 ：デフォルトの名無しさん：2014/11/20(木) 16:40:50.21 ID:2szoNUEC.net

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

187 ：デフォルトの名無しさん：2014/11/20(木) 20:12:20.93 ID:IqIimPum.net

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

188 ：デフォルトの名無しさん：2014/11/21(金) 13:07:27.23 ID:obtZMam2.net

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

189 ：デフォルトの名無しさん：2014/11/21(金) 13:13:28.47 ID:zygDXSz1.net

>>188
ご愁傷さまです。

190 ：デフォルトの名無しさん：2014/11/29(土) 13:01:53.24 ID:OX49RFg5.net

>>190
？

191 ：デフォルトの名無しさん：2014/12/10(水) 19:56:15.27 ID:veDvxwge.net

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 が劣る典型的な一例になる

192 ：デフォルトの名無しさん：2014/12/10(水) 20:24:01.24 ID:Q728OFWk.net

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

193 ：デフォルトの名無しさん：2014/12/10(水) 20:43:29.64 ID:Q728OFWk.net

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

194 ：デフォルトの名無しさん：2014/12/10(水) 21:30:40.85 ID:AwBDqpLr.net

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

195 ：デフォルトの名無しさん：2014/12/10(水) 21:46:37.74 ID:ZY5znPCs.net

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

196 ：デフォルトの名無しさん：2014/12/10(水) 21:50:32.14 ID:gkNqf6iG.net

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


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

197 ：デフォルトの名無しさん：2014/12/11(木) 21:30:20.83 ID:GpAyUabF.net

>>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 ：デフォルトの名無しさん：2014/12/11(木) 21:48:16.84 ID:AENhOzwc.net

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

199 ：デフォルトの名無しさん：2014/12/11(木) 22:44:15.05 ID:GpAyUabF.net

調べてみると、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.net/test/read.cgi/tech/1417333026/9

200 ：デフォルトの名無しさん：2014/12/11(木) 22:55:21.60 ID:aWaBOmKM.net

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

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

201 ：デフォルトの名無しさん：2014/12/11(木) 23:02:23.22 ID:GpAyUabF.net

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

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

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

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

202 ：デフォルトの名無しさん：2014/12/11(木) 23:27:50.83 ID:GpAyUabF.net

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

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

203 ：デフォルトの名無しさん：2014/12/12(金) 00:10:51.51 ID:kNbqUbaQ.net

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

204 ：デフォルトの名無しさん：2014/12/12(金) 09:01:50.64 ID:hLblKLHb.net

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

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

205 ：デフォルトの名無しさん：2014/12/12(金) 18:43:57.39 ID:JZfpq2Ndq

以前も書いたけどPythonistaは走り書き以外でlambdaなんて使わないから。

206 ：デフォルトの名無しさん：2014/12/12(金) 19:05:12.73 ID:1wfis/cT.net

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

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

207 ：デフォルトの名無しさん：2014/12/12(金) 22:20:24.14 ID:ZYnyJXBo.net

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

208 ：デフォルトの名無しさん：2014/12/12(金) 22:38:08.46 ID:hhr7pvhS.net

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

209 ：デフォルトの名無しさん：2014/12/12(金) 22:42:02.66 ID:hLblKLHb.net

>>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 ：デフォルトの名無しさん：2014/12/12(金) 23:33:45.85 ID:ZYnyJXBo.net

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

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


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

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

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

211 ：デフォルトの名無しさん：2014/12/12(金) 23:54:36.75 ID:ZYnyJXBo.net

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

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

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

212 ：デフォルトの名無しさん：2014/12/13(土) 00:01:46.30 ID:HrrHquek.net

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

213 ：デフォルトの名無しさん：2014/12/13(土) 00:13:09.40 ID:HrrHquek.net

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

214 ：デフォルトの名無しさん：2014/12/13(土) 00:39:02.24 ID:gzcIElev.net

>>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 ：デフォルトの名無しさん：2014/12/13(土) 02:01:28.39 ID:6/3yjF6w.net

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

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

216 ：デフォルトの名無しさん：2014/12/13(土) 02:13:23.84 ID:6/3yjF6w.net

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

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

217 ：デフォルトの名無しさん：2014/12/13(土) 02:17:02.89 ID:6/3yjF6w.net

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

これに訂正

218 ：デフォルトの名無しさん：2014/12/13(土) 07:14:46.97 ID:toJAZvUP.net

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

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

219 ：デフォルトの名無しさん：2014/12/13(土) 08:00:50.00 ID:1EyzOdES.net

http://ideone.com/C5hOIB

220 ：デフォルトの名無しさん：2014/12/13(土) 10:42:15.83 ID:ygYpq94K.net

イデオンこわい

221 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 12:26:47.45 ID:sGDpUYPr.net

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

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

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

222 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 12:40:53.92 ID:sGDpUYPr.net

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

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

223 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 14:05:13.26 ID:ZLG0O37u.net

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

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

224 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 14:39:36.41 ID:1EyzOdES.net

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

225 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 20:13:18.59 ID:gzcIElev.net

>>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 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 20:39:14.11 ID:HrrHquek.net

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

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

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

227 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 21:42:39.17 ID:gzcIElev.net

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

その意味であれば、関数型言語と 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 がいくら挑戦しても勝てずに負け続けているのは、
> しごく当然な結果なわけ

228 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 22:07:55.30 ID:HrrHquek.net

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

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

229 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 22:14:57.19 ID:HrrHquek.net

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

230 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 23:06:18.71 ID:gzcIElev.net

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

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

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

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

231 ：名無しさん＠そうだ選挙に行こう：2014/12/13(土) 23:27:26.05 ID:fdPKe7oz.net

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

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

232 ：デフォルトの名無しさん：2014/12/14(日) 00:01:22.20 ID:Gw1grNBM.net

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

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

233 ：デフォルトの名無しさん：2014/12/14(日) 00:38:38.65 ID:iRnVJ1/v.net

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

234 ：デフォルトの名無しさん：2014/12/14(日) 02:05:45.83 ID:sl2oQCLD.net

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

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

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

235 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 10:29:16.99 ID:63H3dBz7.net

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

236 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 14:05:17.21 ID:2A/iPobJ.net

lambda

ラ…ランバダ…

237 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 14:52:29.83 ID:VBy2GaOL.net

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

238 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 15:49:06.80 ID:hNeAViIY.net

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

　　　　　　勇者の父　ランバダ

239 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 15:54:41.51 ID:KqwrXZGg.net

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

240 ：デフォルトの名無しさん：2014/12/14(日) 20:48:34.17 ID:lkA9lgpO.net

>>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 ：デフォルトの名無しさん：2014/12/14(日) 21:10:51.70 ID:Gw1grNBM.net

>>240

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

242 ：デフォルトの名無しさん：2014/12/14(日) 21:42:31.25 ID:k3gK/GUJ.net

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

243 ：デフォルトの名無しさん：2014/12/14(日) 21:59:53.72 ID:Y1wljoB2.net

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

そこが気になるな。

244 ：デフォルトの名無しさん：2014/12/14(日) 22:03:54.59 ID:lkA9lgpO.net

>>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 ：デフォルトの名無しさん：2014/12/14(日) 22:48:49.10 ID:lkA9lgpO.net

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

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

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

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

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

246 ：デフォルトの名無しさん：2014/12/14(日) 22:59:19.75 ID:iRnVJ1/v.net

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

247 ：デフォルトの名無しさん：2014/12/14(日) 23:34:55.92 ID:lkA9lgpO.net

>>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 ：デフォルトの名無しさん：2014/12/14(日) 23:42:14.32 ID:NejhiS1a.net

gaucheいいよね

249 ：デフォルトの名無しさん：2014/12/14(日) 23:49:27.85 ID:lkA9lgpO.net

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



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

250 ：デフォルトの名無しさん：2014/12/14(日) 23:57:54.55 ID:pRYhwT4i.net

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

251 ：デフォルトの名無しさん：2014/12/14(日) 23:58:44.82 ID:iRnVJ1/v.net

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

252 ：デフォルトの名無しさん：2014/12/15(月) 00:02:02.47 ID:wtT+wvpm.net

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

253 ：デフォルトの名無しさん：2014/12/15(月) 00:07:51.10 ID:G9R+2lJx.net

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

254 ：デフォルトの名無しさん：2014/12/15(月) 00:08:50.51 ID:YlFhPVoF.net

lisp-2なのが何となく嫌

255 ：デフォルトの名無しさん：2014/12/15(月) 00:31:53.12 ID:K7E8QpHY.net

>>253 いいよ

256 ：デフォルトの名無しさん：2014/12/15(月) 08:42:12.40 ID:J0ddkTzC.net

>>249
だってRubyなんてマイナー言語どうでも良いし？

257 ：デフォルトの名無しさん：2014/12/15(月) 11:24:34.16 ID:yMEZ5G45.net

>>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 ：デフォルトの名無しさん：2014/12/15(月) 20:13:34.89 ID:AoWRRy2d.net

>>244
> また Ruby の「ブロック付きメソッド呼び出し」とそれらを並べる(=チェーンさせる)スタイルは、
> Apple の新言語である Swift にそのまま採用された
Obj-C が inline Smalltalk が書ける C なのに、Swift が Ruby をまねたみたいなデマはやめてくれる？

それと、 Ruby で関数型スタイルのプログラムを書けるということを、Ruby で書いたら関数型プログラムになるかのように書くのもやめてくれる？

259 ：デフォルトの名無しさん：2014/12/15(月) 21:18:41.61 ID:QjagSoag.net

主観を事実であるかのように語る客観性の無さ

オレオレ定義の根拠を問われて自身の過去の書き込みを引用するコミュニケーション不全

完全に論破されると、自分の間違った主張を相手が言い出したと歴史歪曲しようとする卑怯さ


全てを兼ね備えると>>244みたいな奴になる

260 ：デフォルトの名無しさん：2014/12/15(月) 22:27:41.97 ID:eMlPsgxM.net

>>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 ：デフォルトの名無しさん：2014/12/15(月) 22:40:54.50 ID:G9R+2lJx.net

俺が平安時代に読んだ本だと、iteratorはアイテレータって書かれてたな。
あとhierarchyはハイアラーキだった。

262 ：デフォルトの名無しさん：2014/12/15(月) 22:46:59.52 ID:G9R+2lJx.net

そんなにlispに憧れてるなら、lispを使えばいいのに。

263 ：デフォルトの名無しさん：2014/12/15(月) 22:47:19.92 ID:BuhXHDiL.net

> 1.8 の時代に lambda の挙動が変更されメソッドとして独立しました
> その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません

RubyのProc.newで作られるオブジェクトは
returnの挙動が普通の関数と違ってキモすぎるので
lambdaの方だけでも普通に直したんでしょう

264 ：デフォルトの名無しさん：2014/12/15(月) 23:02:52.91 ID:BuhXHDiL.net

さらに言えば、Rubyのブロック変数のスコープの扱いが1.9で仕様変更されてるけど、
それについてmatz自身が

> それは、Rubyが最初から関数型言語としてスタートしてないからであって、言語が違うからですよね。

と語っているね


http://www.atmarkit.co.jp/news/200907/24/ruby.html

265 ：デフォルトの名無しさん：2014/12/15(月) 23:10:49.42 ID:eMlPsgxM.net

>>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 ：デフォルトの名無しさん：2014/12/15(月) 23:24:28.86 ID:eMlPsgxM.net

>>263
おそらくその通りだと思います


>>264
もしも Matz が Lisper ではなく Schemer であったなら、
違った結果になっていたかもしれませんね

267 ：デフォルトの名無しさん：2014/12/16(火) 00:31:08.98 ID:IiuX/rSM.net

自己レスになりますが、>>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 ：デフォルトの名無しさん：2014/12/16(火) 02:54:32.21 ID:178msYck.net

こんな無駄に遠回しなコード沢山書いてどんだけオナニー好きなんだよ。

269 ：デフォルトの名無しさん：2014/12/16(火) 02:58:06.18 ID:178msYck.net

>>200の爪の垢でも煎じて飲めよ。

270 ：デフォルトの名無しさん：2014/12/16(火) 07:18:26.71 ID:/LiRSDzk.net

>>260
もちろん、本当はただのメソッドであってlambdaは文法要素ではない
あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、その対比としてそう書いたまでだよ
分かりにくかったね、「構文糖のような存在のメソッド」と修正しておくよ

271 ：デフォルトの名無しさん：2014/12/16(火) 07:24:54.85 ID:/LiRSDzk.net

まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら
「真のクロージャ」って用語もおかしいのだと気付いて欲しいな

272 ：1：2014/12/16(火) 07:48:21.23 ID:PApLEh59.net

なんか知らんけど伸びてて嬉しいです
目標はGCスレ超えです

273 ：デフォルトの名無しさん：2014/12/16(火) 08:02:21.01 ID:/LiRSDzk.net

一応lambdaというメソッドの実装された時期について調べてみたら、結構昔から存在自体はしてたのね
元々procと同じなのに字数多い&Procなのにlambdaって覚えにくいのと1.4当時は関数型とか知らんかったからスルーしてたのかな
そこは俺の記憶違いだったわ

274 ：デフォルトの名無しさん：2014/12/16(火) 08:45:33.81 ID:7mh816Ug.net

クロージャがなければ参照カウント型のGCで済むんじゃないか説があるし
ワンチャンあるよ

275 ：デフォルトの名無しさん：2014/12/16(火) 08:47:53.04 ID:7mh816Ug.net

構文糖衣とかいいながら
ラムダって名前から甘そうな印象をうけない
名前が悪いよ考え直すべき

276 ：デフォルトの名無しさん：2014/12/16(火) 08:56:24.06 ID:7mh816Ug.net

クロージャって名前も固いし
意味わかんねえから
貝殻のclamを頑張ってもじって
クリームって名前にするくらいの
努力はあってよかった

277 ：デフォルトの名無しさん：2014/12/16(火) 09:58:24.78 ID:/LiRSDzk.net

>>275
そういう意味ではfunctionを名前ありの関数にもラムダにも使ったJavaScriptは上手いと思う
らむだ何ソレ？な人にも「関数名書かないで使うと無名の関数も作れるよ」って説明で事足りるもんね

278 ：デフォルトの名無しさん：2014/12/16(火) 10:58:59.39 ID:gf3D6lb/.net

ブロックとProc.newとprocとlambdaと->があるRubyはやり過ぎ

279 ：デフォルトの名無しさん：2014/12/16(火) 11:12:47.94 ID:/LiRSDzk.net

>>278
まあ、Rubyは他の組み込みライブラリでも
エイリアスや似たようなメソッド、所属モジュールが違う同様のメソッドとか持つのは普通だからね
俺は昔からproc派、RubyのProcとλ算法は別物だと思うからあの挙動でいいし、早く書けるし

280 ：デフォルトの名無しさん：2014/12/16(火) 22:27:19.26 ID:IiuX/rSM.net

>>270
>あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、

いや「あるかのよう」ではない、>>247 で以下のように、断定的に明記したとおり：
　> まず >>240 で書いたように、Ruby の「ブロック付きメソッド呼び出し」は構文糖だ
Ruby インタブリタの内部では「ブロック付きメソッド呼び出し」と
「値渡しされた Proc オブジェクト」とは別の表現(C構造体)が用いられ、それらを相互変換している
ただし Ruby プログラマの視点では、値渡しされたProc オブジェクトで「あるかのように」
(すなわちファーストクラスとして)ブロックを扱う事ができる、だから「ブロックは構文糖」になる

ブロックを評価するのにメソッド Proc#call が必須(>>257)なのは、また別の理由....
それらをごっちゃにすべきではない


>>271
>まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら

いや「構文糖のような」という比喩表現であれば、何の問題も無い

>「真のクロージャ」って用語もおかしいのだと気付いて欲しいな

>>4 でクロージャ定義を示してから >>201 までソースを明かすのを遅らせたのは意図的だったけど、
「真のクロージャ」という曖昧な表現でいらぬ混乱を与えたことは余計だったと反省している
最初からストレートに「関数型言語のクロージャ」とすべきだったね

281 ：デフォルトの名無しさん：2014/12/16(火) 23:35:24.13 ID:178msYck.net

関数型言語のクロージャと非関数型言語のクロージャはナニが違うですか。

282 ：デフォルトの名無しさん：2014/12/17(水) 00:34:28.88 ID:NwnPjzlT.net

結局、Pythonのクロージャは本物で、Rubyのブロックは偽物って結論になったんか？

283 ：デフォルトの名無しさん：2014/12/17(水) 06:09:12.08 ID:4QPsGplH.net

>>282
彼の中だけではそういうことらしい

284 ：デフォルトの名無しさん：2014/12/17(水) 06:10:48.27 ID:HxoNcsla.net

環境もちこしてる関数っぽいやつならクロージャでいいじゃん

285 ：デフォルトの名無しさん：2014/12/17(水) 06:13:43.20 ID:4QPsGplH.net

って彼の中だけでは逆か

>>284
と言うか元々環境持ち越すのがクロージャの要件でしょ

286 ：デフォルトの名無しさん：2014/12/17(水) 06:16:00.02 ID:HxoNcsla.net

なんで突っ込まれてるのかさっぱりわからん

287 ：デフォルトの名無しさん：2014/12/17(水) 06:21:06.36 ID:4QPsGplH.net

>>286
突っ込んでないよ、超同意してんだよ

288 ：デフォルトの名無しさん：2014/12/17(水) 07:54:17.64 ID:HxoNcsla.net

まじかよ世界は平和だった

289 ：デフォルトの名無しさん：2014/12/17(水) 20:35:47.86 ID:JUumI3zm.net

>>281
もともとクロージャの概念/用語は関数型言語で生まれたものだから、
「非関数型言語のクロージャ」とは：
　　「関数型言語のクロージャ」の定義に対して、どれくらい忠実に実装されているか？
という相対的な評価になるね

290 ：デフォルトの名無しさん：2014/12/17(水) 21:10:46.15 ID:cFsqVLS5.net

そして、オリジナルのクロージャーが
一番優れているとかいう信者が現れるわけかｗ

普通はオリジナルを改良した方が
優れているんだがな。

291 ：デフォルトの名無しさん：2014/12/17(水) 21:39:32.52 ID:JUumI3zm.net

>>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 ：デフォルトの名無しさん：2014/12/17(水) 21:47:14.69 ID:JUumI3zm.net

>>282 を一部訂正

X：JavaScript の関数リテラルは任意の書けるから
O：JavaScript の関数リテラルは任意の文が書けるから

293 ：デフォルトの名無しさん：2014/12/17(水) 22:23:00.08 ID:NwnPjzlT.net

>>291
再帰関数よりwhileループが読みやすいレベルの人間が
関数型プログラミングについて語るなんて滑稽すぎる

294 ：デフォルトの名無しさん：2014/12/17(水) 22:32:56.00 ID:NwnPjzlT.net

>>291
あと、>>208じゃなくて>>203を評価すべきだと思うんだけど、
なんでワザワザ可読性を落としてる方を評価してるの？

まさか、Rubyでinjectは使って良いけど、Pythonでapplyfは使っちゃダメとでも言うつもり？

295 ：デフォルトの名無しさん：2014/12/17(水) 22:42:41.33 ID:KZ4YaCx1.net

可読性の良し悪しなんて定量的ではないものを評価対象にするとか

296 ：デフォルトの名無しさん：2014/12/17(水) 22:47:17.42 ID:ffqYUKYZ.net

> Python の lambda 構文は式しか書けないという制限があるから、
> クロージャ固有の局所環境を持つことができない


def make_f(n): return lambda x: x + n
f = make_f(1)
n = 1000
f(1) #=> 2

こういう風に、（引数以外の変数を）実行時の環境じゃなくて
自身が定義された環境で解決できればクロージャだよ。
この場合は変数nのことね。

297 ：デフォルトの名無しさん：2014/12/17(水) 23:03:51.76 ID:dyHF3Jr0.net

>>289
レキシカルクロージャってSchemeが最初だと思うけど、
Schemeって純粋な関数型言語じゃないよね。

298 ：デフォルトの名無しさん：2014/12/17(水) 23:50:33.95 ID:JUumI3zm.net

>>294
お題に対して「Python だけがわざわざ関数 applyf をユーザ定義しなければならない」ことを問題視している
>>203 のコードは「お題を(勝手に改変せず)インラインで書ける」という観点だと(評価以前に)失格だ

もしも Python コミュニティにおいて関数 applyf が常識的に認知されていたならば、
(map/filter/reduce 等と同様に) applyf は組み込み関数として実装されていたはず
なお、組込み関数の実装レベルは言語によって差異があるものだから、
公平性を考慮して functools のような標準ライブラリを import するのは認める

また Ruby のメソッド Enumerable#inject に対応する Python の関数は reduce だよ
Python で組込み関数 reduce を使うのは、まったく問題無い

299 ：デフォルトの名無しさん：2014/12/17(水) 23:55:13.45 ID:dyHF3Jr0.net

ていうか、さらっと1個の式で書けないような処理はインラインに書こうとするなよ
っていうのがpythonの求めるところなんじゃないの？

300 ：デフォルトの名無しさん：2014/12/18(木) 00:12:23.41 ID:SaitqfQN.net

>>203 はインラインでは書けていないけど、>>208 と比べれば可読性の高いコードであると思うから、
>>294 の主張を受け入れて >>291 を以下のように一部改訂する（＊ で始まる行を変更している）

改定前：
　・高階関数 map に与えるクロージャをインラインで書ける
　　　[Python：X]
　　　・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>208)
＊　　・このため、一般には(インラインで書くのはあきらめて)関数定義を使わざるをえない
　・参照透明性のある関数型プログラミングで書ける
＊　　[Python：X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>208)

改訂後:
　・高階関数 map に与えるクロージャをインラインで書ける
　　　[Python：X]
　　　・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>208)
＊　　・このため、一般には(インラインで書くのはあきらめて)関数定義または変数宣言(>>203)を使わざるをえない
　・参照透明性のある関数型プログラミングで書ける
＊　　[Python：X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>203,205)

301 ：デフォルトの名無しさん：2014/12/18(木) 00:16:28.27 ID:5LPNbvYA.net

むしろ標準で用意されてなくてもユーザ定義で拡張できるのは
言語として筋が良いといえる

302 ：デフォルトの名無しさん：2014/12/18(木) 00:18:19.46 ID:wQzGbOYd.net

謎の標準ライブラリ縛りが入りましたw

303 ：デフォルトの名無しさん：2014/12/18(木) 00:22:42.78 ID:Xu+bpXu3.net

1個の式で済む以上の事をやろうとする処理に名前を付ける事が、なぜ可読性の低下につながるの？

304 ：デフォルトの名無しさん：2014/12/18(木) 00:29:24.93 ID:wQzGbOYd.net

再帰は可読性低いって連呼しててワロタ
Rubyユーザって、ブロック使ってるだけで関数型だと思ってるの？

305 ：デフォルトの名無しさん：2014/12/18(木) 00:35:38.77 ID:Xu+bpXu3.net

Schemeは普通ならループで済むような事まで再帰で書くぜ

306 ：デフォルトの名無しさん：2014/12/18(木) 00:44:04.09 ID:4kRgXtNb.net

再帰よりnamed let使おう

307 ：デフォルトの名無しさん：2014/12/18(木) 00:52:42.96 ID:Xu+bpXu3.net

named let は再帰でしょ？

308 ：デフォルトの名無しさん：2014/12/18(木) 01:28:37.32 ID:4kRgXtNb.net

書いた後に思った

309 ：デフォルトの名無しさん：2014/12/18(木) 08:20:12.81 ID:ETi/Ct7F.net

>>304
彼だけだよ

310 ：デフォルトの名無しさん：2014/12/18(木) 08:27:40.63 ID:9iQd+rLQ.net

lispおじさんに言わせれば
全部lispのパクりだから
全部クロージャで問題ないよ

311 ：デフォルトの名無しさん：2014/12/18(木) 09:21:04.09 ID:f+DPSsFx.net

なんでクロージャスレでClojureを話題にしないの？

312 ：デフォルトの名無しさん：2014/12/18(木) 09:50:43.10 ID:ZOTu6c+H.net

>>311
若いときは買ってでもするものなあ〜んだ？

313 ：デフォルトの名無しさん：2014/12/18(木) 12:49:08.51 ID:nVA5J83n.net

>>312
ゲーム

314 ：デフォルトの名無しさん：2014/12/18(木) 19:33:48.97 ID:Xo1YvlzDq

ClosureCL…(ﾎﾞｿｯ

315 ：デフォルトの名無しさん：2014/12/18(木) 19:41:50.11 ID:5ReW54RD.net

>>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 ：デフォルトの名無しさん：2014/12/18(木) 22:22:25.63 ID:2b1ZQukZ.net

>>312
SEX

317 ：デフォルトの名無しさん：2014/12/18(木) 23:09:02.06 ID:SaitqfQN.net

>>315
Standard ML で素直に末尾再帰を使って書いてみた
　http://ideone.com/WpChMC

318 ：デフォルトの名無しさん：2014/12/19(金) 00:07:27.38 ID:lMWP4GlC.net

>>317
おおっ！わざわざどうも！
SMLとOCamlの関係だからこういう似たような感じになるのかな？
それともループを再帰に置き換えたらどうせどの言語でもこんな感じかな？

それにしても関数型言語なるものを知るにつれて思うのは、
再帰についてはすがすがしいが、
それ以外についてはタイプ量が増えがちってこと。
ハッシュテーブルひとつ準備するのにもウダウダ。
関数型どうのというより、個別の言語によるのかもしれないけど…。

319 ：デフォルトの名無しさん：2014/12/20(土) 00:24:39.20 ID:0cpPf2uS.net

>>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 ：デフォルトの名無しさん：2014/12/20(土) 00:32:09.09 ID:0cpPf2uS.net

（＊　>>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.net/test/read.cgi/tech/1345123070/28
また ML や Haskell の強力な型推論は、データ型に関する矛盾(=バグ)が存在しないことを(実行の前に)証明しますが、
動かしては書き直す(いわゆるトライ＆エラー)が一般的なスクリプトプログラミングには不向きだと考えます

（＊　これで終わり　＊）

321 ：デフォルトの名無しさん：2014/12/20(土) 07:17:42.63 ID:tzPxF8Oh.net

長い
3行でまとめろ

322 ：デフォルトの名無しさん：2014/12/20(土) 12:12:13.43 ID:PEBuGla8.net

珍しく普通に相手にしてもらって
うれしくてたまらない
オレオレクロージャくんであった

323 ：デフォルトの名無しさん：2014/12/20(土) 16:08:48.96 ID:5dXZUu33.net

>>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 ：デフォルトの名無しさん：2014/12/20(土) 16:23:01.32 ID:a9XjC0LN.net

源クロウジャ義経

325 ：デフォルトの名無しさん：2014/12/20(土) 19:01:20.98 ID:tzPxF8Oh.net

>>322
分かりやすいですー

326 ：デフォルトの名無しさん：2014/12/21(日) 00:04:04.16 ID:YWufr8fT.net

>>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 ：デフォルトの名無しさん：2014/12/21(日) 09:15:25.48 ID:KrmABo99.net

TCO無くて正格評価なPythonでは
unfoldはループ&ジェネレータで実装した方が良いね
それと文字列に限定する意味って無いよね

http://ideone.com/e1fKAL

328 ：デフォルトの名無しさん：2014/12/21(日) 16:48:41.14 ID:MvQSKDIW.net

この話題クロージャとか特に関係なく、Pythonの無名関数には文を書けず式しか書けないという単純な事実の指摘でＯＫ？
関数型プログラミングのラムダとしては困らないが、手続き型言語における無名関数としては不便だろうな
自分はPythonを使わないので、Pythonでの「普通の」プログラミングスタイルがどっちなのかは知らん

329 ：デフォルトの名無しさん：2014/12/21(日) 17:05:17.75 ID:MvQSKDIW.net

Hackで適当に書いてみたら本体は一行だった。PHPの緩さにラムダ加わるの最強

$strings = array_map($n ==> array_reduce(str_split($n), ($s, $d) ==> $s . $digitNames[$d]), $numbers);

330 ：デフォルトの名無しさん：2014/12/21(日) 17:15:45.30 ID:KrmABo99.net

そんなので良ければPythonでも一行

strings = [''.join(digitNames[x] for x in str(n)) for n in numbers]

331 ：デフォルトの名無しさん：2014/12/21(日) 17:21:26.20 ID:MvQSKDIW.net

あれ、それdigitNames[x]のxに文字列で渡ると思うけど、Pythonも勝手に数値に変換してくれるんだっけ？
整数に変換してやらないと駄目な記憶があっていちいち面倒くさいと思ってた

332 ：デフォルトの名無しさん：2014/12/21(日) 18:11:16.63 ID:axFrURca.net

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 ：デフォルトの名無しさん：2014/12/21(日) 18:21:39.18 ID:MvQSKDIW.net

最強言ったから気に食わなかったならスマンカッタ

PHPの緩さは、こういうのが動くところ。>>329でそのまま動く
$digitNames = ['Zero','One','Two','Three','Four','Five','Six','Seven','Eight','Nine','.'=>'Point','-'=>'Minus'];
$numbers = [1.234, -5.4321];

334 ：デフォルトの名無しさん：2014/12/21(日) 23:04:35.55 ID:YWufr8fT.net

>>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 ：デフォルトの名無しさん：2014/12/22(月) 08:52:28.54 ID:6avCYBJ9.net

Pythonの場合リストを返したかったら list(unfold(f, x)) で良くね？
毎回 s += a 等やって組み立てるよりも速いぞ

336 ：デフォルトの名無しさん：2014/12/22(月) 09:03:18.85 ID:6avCYBJ9.net

あ、もしかしてunfoldlじゃないからダメって言ってんの？
unfoldには unfoldr と unfoldl の二種類あって、HaskellではPreludeにあるのはunfoldrだけだぞ

337 ：デフォルトの名無しさん：2014/12/22(月) 09:04:46.38 ID:6avCYBJ9.net

ちなみに>>334が自信満々に貼ってる方のHaskellのunfoldの定義はunfoldrの方なw

338 ：デフォルトの名無しさん：2014/12/22(月) 09:07:58.19 ID:ZCDWZl5G.net

unfold :: (B -> Maybe (A, B)) -> B -> [A]
じゃないから駄目とか言っといて、なんで出してる実装はことごとく
unfold :: (B -> Maybe (A, B)) -> B -> A
なの？　バカなの？

339 ：デフォルトの名無しさん：2014/12/22(月) 14:26:58.64 ID:51sTiTTJ.net

またオレオレ定義君がやらかしちゃったかー

340 ：デフォルトの名無しさん：2014/12/22(月) 21:08:27.40 ID:8h2AGQmm.net

cにクロージャくれよっておもってたけど
今ならgoがあるんだよな

341 ：デフォルトの名無しさん：2014/12/22(月) 21:10:47.28 ID:VRBNRD9f.net

C++使ったら？スコープ抜けた際どうなるか、必要ならコピーを持たせよう、とかスマポにするかーとか、考える必要はあるけど

342 ：デフォルトの名無しさん：2014/12/22(月) 21:16:46.96 ID:6skO2mFq.net

>>340
clangならblocksが使えるんじゃないかしら

343 ：デフォルトの名無しさん：2014/12/23(火) 06:28:08.32 ID:pszL50YR.net

ほー objc じゃなくても使えるのか。
まあ objc に c のソースだけ食わせて使ってもいいんだけど。

344 ：デフォルトの名無しさん：2014/12/23(火) 11:28:17.27 ID:St4HMSPr.net

boost lambdaで怖い思いしたから
c++はng
コンパイルエラーから黒魔術なコード出されてもこまる

345 ：デフォルトの名無しさん：2014/12/23(火) 11:30:55.43 ID:0dLhalMI.net

そういうのはreplで対話的に書けたほうがいいな

346 ：デフォルトの名無しさん：2014/12/23(火) 14:09:04.60 ID:Og1JN7U7.net

このスレのおかげでクロージャの良さと
Ruby信者のキモさが分かりました
ありがとうございました

347 ：デフォルトの名無しさん：2014/12/27(土) 00:25:14.89 ID:randw1SU.net

クロージャなんて最近の言語は大抵あるからね
次に関数型言語からパクって欲しいのはパターンマッチ

348 ：デフォルトの名無しさん：2014/12/29(月) 07:25:36.12 ID:Br8mMuyh.net

disると公開される

349 ：デフォルトの名無しさん：2014/12/29(月) 16:50:56.24 ID:9aAL2Pj2.net

まぁ別にいらないっちゃいらないな。
最近の言語はいろいろ付けすぎだわ。
もっと仕様単純でいいよ。

350 ：デフォルトの名無しさん：2014/12/29(月) 17:19:30.86 ID:LxjJzYoX.net

パターンマッチの無い言語にパターンマッチを付けられるような言語がいい

351 ：デフォルトの名無しさん：2014/12/29(月) 19:45:55.93 ID:NKff8BVB.net

>>350
プリプロセッサを使えば、どんな言語でも
なんだって出来るんじゃね？

352 ：デフォルトの名無しさん：2014/12/30(火) 17:09:02.43 ID:AU/nggqJ.net

その万能プリプロセッサがあればいいんだけど

353 ：デフォルトの名無しさん：2014/12/30(火) 18:06:56.67 ID:mxKZGqd3.net

m4通すとか？

354 ：デフォルトの名無しさん：2014/12/30(火) 18:40:21.70 ID:AU/nggqJ.net

その言語処理系を書かた言語のコードを直接書き変えるような書き方じゃなくて
その言語自体で新しい表現(パターンマッチとか)を定義出来るようにするってこと

355 ：デフォルトの名無しさん：2014/12/30(火) 19:32:00.99 ID:tU/2zS2Z.net

>>350
lispおじさんだ！

356 ：デフォルトの名無しさん：2014/12/30(火) 20:40:47.63 ID:LKC757rT.net

lispでマクロ使えばおk

357 ：デフォルトの名無しさん：2014/12/31(水) 23:19:03.80 ID:tqgvohnx.net

>>354
たぶんschemeにドハマリするタイプ

358 ：デフォルトの名無しさん：2015/01/01(木) 00:15:11.77 ID:6s4ScpeL.net

on lispとかlet over lambdaがあるcommon lispの方がいいんじゃね

359 ：デフォルトの名無しさん：2015/01/01(木) 08:49:44.48 ID:Vz2QaCIS.net

あなほりマクロ怖い

360 ：デフォルトの名無しさん：2015/01/01(木) 19:26:59.51 ID:LWrX8qsS.net

やっぱりpythonとかhaskellのコードと比べると
専用の構文があった方がスッキリ書ける
でもそうすると自由度が無くなってマクロがうまく使えないジレンマ

361 ：デフォルトの名無しさん：2015/01/01(木) 19:31:53.89 ID:LWrX8qsS.net

一応リーダマクロを使えば解決するんだけど結局使わなくなる

362 ：デフォルトの名無しさん：2015/01/02(金) 09:58:20.63 ID:ie8IusfS.net

lispおじさんのせいで
すっかりマクロ談義スレになったな

363 ：デフォルトの名無しさん：2015/01/02(金) 10:14:10.05 ID:PL75YfkA.net

真のクロージャとマクロ、どっちがマシか難しいところだな

364 ：デフォルトの名無しさん：2015/01/02(金) 11:28:56.61 ID:Ur5QsT6D.net

二つのいいところを組み合わせたものが最強ではないだろうか？

つまりマクロージャー

365 ：デフォルトの名無しさん：2015/01/02(金) 12:10:26.52 ID:ie8IusfS.net

マクロにコンテクストが付いて回るclの事だよねそれ

366 ：デフォルトの名無しさん：2015/01/02(金) 15:30:32.04 ID:/upm+g4t.net

マクロとクロージャを組み合わせればOOPも継続も後から付けられる

367 ：デフォルトの名無しさん：2015/01/02(金) 15:37:48.79 ID:Ur5QsT6D.net

いろんなことができる。そうマクロージャならね！

368 ：デフォルトの名無しさん：2015/01/02(金) 20:00:41.84 ID:ZuY3pBgY.net

>>366
継続渡しではないですよね？
マクロとクロージャーで継続をどう実装するか
ぱっとは思いつかなかったのでよかったら教えてください。

369 ：デフォルトの名無しさん：2015/01/02(金) 20:28:34.80 ID:UWr+Udi0.net

onlispでは継続を表わすクロージャを引数で渡してそれをマクロで包んでる
これだと使う側が末尾呼出的に書かないといけない縛りがある
cl-contは式をwithマクロで包んでその式をcodewalkしてcps変換してる

370 ：デフォルトの名無しさん：2015/01/02(金) 21:04:50.09 ID:ZuY3pBgY.net

ありがとうございます。On Lisp 読んでみます。

371 ：1：2015/01/09(金) 13:33:15.35 ID:3m5OEfmN.net

そもそも関数が一級オブジェクトである必要があるのかどうか疑問が出てきました
ifelse( aaa, xxx,
ifelse( bbb, yyy,
ifelse( ccc, zzz,
　　　　　　iii )))
　　　　　　　↑死ね
IDE使えってことなんでしょうけど認知に負荷をかける言語仕様は間違ってると思うんですよね
これよりはメソッドチェーンの方がかなりスマートだと思う
foo(aaa){xxx}.bar(bbb){yyyy}.baz(ccc){zzz}

372 ：デフォルトの名無しさん：2015/01/11(日) 21:16:33.98 ID:8HLn7hr5.net

それだと全てのメソッドで条件分岐を想定した実装にしなくちゃいけなくなるのでは

373 ：デフォルトの名無しさん：2015/01/16(金) 01:40:03.14 ID:U7RTYgR7.net

Pythonはパターンマッチ以前にSwichtすらない

374 ：デフォルトの名無しさん：2015/01/16(金) 08:39:36.86 ID:oLGQ6wLb.net

>>373
そんなもんがある言語を見たことないが

375 ：デフォルトの名無しさん：2015/01/16(金) 23:23:44.50 ID:obgM8cFp.net

なんかドイツ語？みたいな切り方だな

376 ：デフォルトの名無しさん：2015/01/21(水) 16:33:15.48 ID:Out9u5nx.net

ゲルマンおじさんこわい！

377 ：デフォルトの名無しさん：2015/01/22(木) 01:37:45.45 ID:8pwMw7VT.net

スウィヒトとか読むの？ドイツ語ってよくわからんタイミングで濁るイメージあ？からジットとかかな

378 ：デフォルトの名無しさん：2015/01/22(木) 08:08:05.98 ID:VatMjg6z.net

スヴィヒトだな、あえてカタカナを当てれば

379 ：デフォルトの名無しさん：2015/01/24(土) 00:56:47.04 ID:hSO7J5Oj.net

中二病みたい

380 ：デフォルトの名無しさん：2015/01/27(火) 21:37:55.87 ID:x1TLH4fz.net

ここまでnonlocalなし

381 ：デフォルトの名無しさん：2015/11/26(木) 03:43:18.04 ID:9L/RhMYwv

関数を返す関数を定義するときにはいる

382 ：デフォルトの名無しさん：2016/01/10(日) 19:01:54.47 ID:sdj7zt3O.net

Objective-Cのblocksが便利だというからいろいろ読んでみたが
使い道がよーわからん。他言語のクロージャやラムダだということで
他言語のクロージャやラムダについて読んでたらもっと混迷が深まった。

383 ：デフォルトの名無しさん：2016/03/29(火) 09:21:36.23 ID:/c8bAcK4.net

サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート

384 ：デフォルトの名無しさん：2016/05/01(日) 14:33:24.76 ID:tKi6j9CT.net

匿名通信（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 ：デフォルトの名無しさん：2018/06/30(土) 19:46:44.69 ID:AmpLvy/F.net

保守

386 ：デフォルトの名無しさん：2018/07/05(木) 02:00:11.95 ID:RfoszcD2.net

S8R

387 ：デフォルトの名無しさん：2018/07/19(木) 09:21:29.22 ID:DyCUHSWz.net

関数型で参照透過性とか言ってるのに
クロージャにしたら意味ないじゃん。
やっぱりオブジェクト指向のほうが優れてるの？

388 ：デフォルトの名無しさん：2018/07/19(木) 15:23:16.35 ID:n84GXL2z.net

ラムダ式はともかくクロージャなんて純粋な関数型では使わないだろう

389 ：デフォルトの名無しさん：2018/08/03(金) 08:55:18.28 ID:4j7d3TQF.net

関数型ではクロージャーは当たり前
というより関数とクロージャーに意味論的な違いはない
特定のパターンの書き方の関数をそう呼んでるだけ

390 ：デフォルトの名無しさん：2018/08/03(金) 14:55:46.25 ID:fAsZ4eFv.net

>>389
ラムダ式と混同してる？

391 ：デフォルトの名無しさん：2018/08/03(金) 20:20:49.90 ID:uYN9BNxM.net

>>390
混同もなにも根元的にすべてがラムダ項なのが関数型だろ
ひょっとして匿名関数をラムダと呼んでるニワカ？

392 ：デフォルトの名無しさん：2018/08/04(土) 19:50:14.71 ID:47wZhJf+.net

クロージャとラムダを混同してないかって事じゃね？

393 ：デフォルトの名無しさん：2018/08/04(土) 20:43:06.82 ID:GiulTy4Z.net

なんでじゃねじゃね言い合うのか
なぜ本人同士が出てきてやりあわないのか

394 ：デフォルトの名無しさん：2018/08/05(日) 00:06:57.49 ID:79cO6f6/.net

>>392
> クロージャとラムダを混同してないかって事じゃね？

そう読解した上での >>391 だっての
お前も表層的なsyntaxしか理解してないくちだな

395 ：デフォルトの名無しさん：2018/08/05(日) 00:35:34.24 ID:GRCljFf8.net

お前はさながらコミュ症と称されるくちだなｗ

396 ：デフォルトの名無しさん：2018/08/05(日) 19:05:22.36 ID:2n69scci.net

これはひどい

397 ：デフォルトの名無しさん：2018/08/23(木) 08:46:43.71 ID:NPcuqlt3.net

苦労じゃー
ら無駄