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

1 名前：デフォルトの名無しさん [2014/11/08(土) 13:11:47.84 ID:6V2MLUHb.net] 関数型言語に必ずくっついてるこれ いらんでしょ？匿名クラスで充分でしょ 181 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 01:32:42.88 ID:fhZ8V3Hu.net] >>180 >>171が正解と考えれば全く矛盾してないので、お前が間違ってるんだよ 182 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 09:44:37.50 ID:BfhGUngW.net] with構文はスコープから抜ける時にclose的な関数を必ず呼び出してくれる保証があるけど、 Rubyのブロックにはそんな保証は無い だからRubyではウッカリcloseを忘れても分かりにくい そういうのは良くない 183 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 11:08:08.37 ID:nwROesTX.net] >>180 > Wikipedia の記事が常に 100% 正しいと思っているのかな？ 思ってないけど、あんたが言っていることよりかは 正しいと思うね。 だって、あんたの言うことのほうが正しいなら wikipediaを修正すればいいわけだから。 184 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 12:57:07.44 ID:5gFBGGbj.net] なんだ、この偏執狂たちの罵り合いはw そんなことより、問題。 若い内に買ってでもしろ、と言われるものはなぁんだ？ 185 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 15:15:51.24 ID:W3M4RtQD.net] ああ、let-inが無いからpythonのはクロージャじゃないって主張か。 斜め上だな。 186 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 16:40:50.21 ID:2szoNUEC.net] 環境と変数を手軽に包めるのは有難いけどなあ XMLベースのジョブ管理言語とか ちょっとしたVM作るときに 継続の表現にクロージャなしだとだるいよ さらに無名クラスも無い言語だと 本物のVM作らなきゃいけなくなる 187 名前：デフォルトの名無しさん mailto:sage [2014/11/20(木) 20:12:20.93 ID:IqIimPum.net] https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Closures 188 名前：デフォルトの名無しさん mailto:sage [2014/11/21(金) 13:07:27.23 ID:obtZMam2.net] >>184 セックス…かな 年とると立たなくなるから 189 名前：デフォルトの名無しさん mailto:sage [2014/11/21(金) 13:13:28.47 ID:zygDXSz1.net] >>188 ご愁傷さまです。 190 名前：デフォルトの名無しさん mailto:sage [2014/11/29(土) 13:01:53.24 ID:OX49RFg5.net] >>190 ？ 191 名前：デフォルトの名無しさん mailto:sage [2014/12/10(水) 19:56:15.27 ID:veDvxwge.net] Swift スレでクロージャの話題で荒れそうだったので、こちらへ移動しとく 　peace.2ch.net/test/read.cgi/tech/1415860741/153 -- Swift や Ruby を含む多くの言語では常識であるけど Python では異なるものとして、 関数型言語に由来した(無名関数やラムダ式とも呼ばれる)クロージャがある たとえば "The Swift Programming Language" の "Closure" の章にある map メソッドを使った サンプルコードは、Ruby でも同じスタイルの良く似たコードで書き直せる： 　ideone.com/TsGD6B これは Ruby だけでなく、JavaScript でも同じ Swift や Ruby と比べて構文が簡潔な JavaScript ではいくらか冗長にはなるけれど、 何の苦もなく Swift と同じスタイルで書き直せる： 　ideone.com/74oNVU 同様に、「あるテーブルから特定の行だけを抽出し、加工して、集計する処理」は、 Swift だと table.filter { .... }.map { .... }.reduce { .... } とメソッドを連結(チェイン)させた式で書ける これは Ruby なら table.select { .... }.map { .... }.inject { .... } と書き直せる ここで、クロージャ内の ..... の部分には、上記のサンプルのように「任意の文(statements)が書ける」 もしかすると、いやこんなの高階関数のプログラミングを知っている人なら当たり前だろ、と感じるかもしれない ところが Python だけはクロージャの本体に(任意の文ではなく)「式(expression)しか書けない」： 　ideone.com/tDaDkL　　# --> Syntax Error になってしまう だから、他の言語のクロージャに相当するコードを(名前のある)関数としてわざわざ宣言しなければならない： 　ideone.com/R7twCQ 結果として、Python は手続き型プログラミングであれば簡潔で可読性に優れたコードが書けるスクリプト言語だけれど、 関数型プログラミングには適さず、こうした関数型プログラミングは推奨されていないらしい(これを "酸っぱい葡萄" と言ふ) 　peace.2ch.net/test/read.cgi/tech/1345123070/70-71 これが Swift や Ruby 等と比較すると、関数型プログラミングで Python が劣る典型的な一例になる 192 名前：デフォルトの名無しさん mailto:sage [2014/12/10(水) 20:24:01.24 ID:Q728OFWk.net] と言うかどう見てもこないだまでこのスレに居た俺俺定義の人ですな 193 名前：デフォルトの名無しさん mailto:sage [2014/12/10(水) 20:43:29.64 ID:Q728OFWk.net] よく見たら、そのスレで誘導かけてるの、話振ったお前本人じゃねーかw 俺俺定義が認められなかったから逃げて来たのか？ 194 名前：デフォルトの名無しさん mailto:sage [2014/12/10(水) 21:30:40.85 ID:AwBDqpLr.net] クロージャの定義は>>4って書かれてたがStandard MLにラムダ式はない けど当然SMLにはクロージャがあるわけで ソースはThe Definition of Standard ML, revised edition 195 名前：デフォルトの名無しさん mailto:sage [2014/12/10(水) 21:46:37.74 ID:ZY5znPCs.net] 関数型プログラミングってどういうのを指して言ってるんだろ 196 名前：デフォルトの名無しさん mailto:sage [2014/12/10(水) 21:50:32.14 ID:gkNqf6iG.net] >>191のサンプルが手続き型全開の書き方で笑った >>195 関数（に名前付けたくない）型プログラミング 197 名前：デフォルトの名無しさん mailto:sage [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 　　　　www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/13_Function_Definition.html ・Python では、その言語リファレンスで「ラムダ式」と呼ばれている： 　　・6. 式 (expression) ― Python 3.4.2 ドキュメント 　　　docs.python.jp/3.4/reference/expressions.html#lambda 198 名前：デフォルトの名無しさん mailto:sage [2014/12/11(木) 21:48:16.84 ID:AENhOzwc.net] >>197 肝心のクロージャの定義の引用はまだですか？ 俺俺定義はお腹いっぱいなんですよ 199 名前：デフォルトの名無しさん mailto:sage [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) 　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) 　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) 　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 　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 　www.artima.com/weblogs/viewpost.jsp?thread=147358 まさに「みんなを納得させるほどの「結論」じゃない」というのは、こういう状況を指しているんだろね.... 　peace.2ch.net/test/read.cgi/tech/1417333026/9 200 名前：デフォルトの名無しさん mailto:sage [2014/12/11(木) 22:55:21.60 ID:aWaBOmKM.net] >>191 普段Python書かないからPythonicではないかもしれないが、だいたいこんな感じだろう。 ideone.com/0vAET2 それで、何が問題なんだ？ 201 名前：デフォルトの名無しさん mailto:sage [2014/12/11(木) 23:02:23.22 ID:GpAyUabF.net] >>198 ではクロージャ定義の引用元ソースを示そうね 答えは書籍「計算機プログラムの構造と解釈」、いわゆるSICP本だ その中の節「3.2.1 評価の規則」に手続きオブジェクトが、いわゆるクロージャに対応する 　sicp.iijlab.net/fulltext/x321.html そしてクロージャを視覚化したのが、 このページの図3.2にあるオタマジャクシの卵が２つ並んだ図形になる 単純な話だと思うけど、難しいかな？ 202 名前：デフォルトの名無しさん mailto:sage [2014/12/11(木) 23:27:50.83 ID:GpAyUabF.net] >>200 関数を宣言せずに書くという制約の元ですから、とてもPythonらしいコードだと思います しかもループの代わりに関数再帰を使っているのですから、より関数型プログラミングらしいとも言えます ただし、元々 Swift で書かれていたサンプルコードを各 LL へと書き直しているのですから、 もし以下の点を改善できれば(Pythonらしさという意味では)完璧でしょう： ・中間変数 f を宣言せず、リスト内包式の中にラムダ式をインラインで書く ・Swift のコードは辞書を使っているのですから、それを(勝手に)配列 digits へ改変せず、 　Python でも(Ruby や JavaScript と同様に)辞書を使って書く 203 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 00:10:51.51 ID:kNbqUbaQ.net] >>202 注文が多いな。 ideone.com/KWnSgA 204 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 09:01:50.64 ID:hLblKLHb.net] >>201 で、どこに「クロージャは無名関数でなければダメ」と書いてあるの？ 「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが？ いい加減、誤摩化して逃げ回るのは止めたら？ 205 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 18:43:57.39 ID:JZfpq2Ndq] 以前も書いたけどPythonistaは走り書き以外でlambdaなんて使わないから。 206 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 19:05:12.73 ID:1wfis/cT.net] 別にPythonのラムダに式が書けないから問題だと言うだけなら荒れねーよ そこで「だからPythonにはクロージャが無い」って言う 決して成り立たない等式を持ち込むから「いやそのりくつはおかしい」って言われてんのに そしたら既存のクロージャという用語の定義のほうを弄ろうとするから叩かれてんだろうが プログラミングに例えるなら、お前は自分の書いた関数で 組み込み整数型の値にそのままリスト処理を適用しようとして例外吐かれたから、と 整数クラスのほうがリストとして振る舞うようにメソッドを書き換えようとしてる 207 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 22:20:24.14 ID:ZYnyJXBo.net] >>203 お疲れさまです 中間変数 f は消えましたが、今度は中間変数 applyf が現れてしまいましたね.... 208 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 22:38:08.46 ID:hhr7pvhS.net] >>207 ideone.com/zAN4uA 209 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/12(金) 23:54:36.75 ID:ZYnyJXBo.net] >>208 ありがとうございます、これで完璧ですね これで「何が問題なんだ？(>>200)」という議論を続けることができます 具体的には、>>191 の Swift/Ruby/JavaScript で書かれたコードと >>208 の Python で書かれたコードを比較して、 「どちらがわかりやすいか/読みやすいか/書きやすいか？」という話です で、これらは主観による評価ですから、 いくら議論しても誰もが納得できる結論へとは収束しないでしょう すべての Pythonista にとって >>208 が読みやすく書きやすいと感じるのなら、 それはそれでいいんじゃないでしょうか 212 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 00:01:46.30 ID:HrrHquek.net] 一時変数を消すためにそんなパズルみたいな事やって読みやすいわけないだろw 213 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 00:13:09.40 ID:HrrHquek.net] >>210 schemeではlambdaが本質的なもので(define (f x) 〜)はシンタックスシュガーだけど、 pythonではdefが本質的なものでlambdaの方がシンタックスシュガーなのでは。 214 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 00:39:02.24 ID:gzcIElev.net] >>209 Wikipedia 英語版の解説と同じに見えるけど、何を言いたいのかな？ ・Closure (computer programming) - Wikipedia, the free encyclopedia 　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 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 02:01:28.39 ID:6/3yjF6w.net] >>4 >クロージャを識別子に束縛したものが一般的な「関数宣言」である よかった、pythonにもちゃんとクロージャあった 216 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 02:13:23.84 ID:6/3yjF6w.net] foo = lambda bar: bar これはクロージャである っていうのが偽であることを定義から証明すればいいんじゃないかな 反例あげればいいだけだよね？ 217 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 02:17:02.89 ID:6/3yjF6w.net] あ、まちがえたそれはクロージャじゃない def foo(): bar = 1 これに訂正 218 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 07:14:46.97 ID:toJAZvUP.net] >>211 それはPythonの書き方じゃないんだよ。 お前が>>202で指定したから、結果的にそうなっただけで。 それで、結局「クロージャを書けない」から「読みにくい」に問題をすり替えて終わりか？ 219 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 08:00:50.00 ID:1EyzOdES.net] ideone.com/C5hOIB 220 名前：デフォルトの名無しさん mailto:sage [2014/12/13(土) 10:42:15.83 ID:ygYpq94K.net] イデオンこわい 221 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 12:26:47.45 ID:sGDpUYPr.net] >>210 > もちろん「クロージャは無名関数でなければダメ」とは書かれていない なんだ、Pythonのdefで良かったんだ 知らないみたいだから教えてあげるけど、Pythonではdefで関数定義すると 環境を持ったクロージャになってるんだよ、勉強になったね 222 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 12:40:53.92 ID:sGDpUYPr.net] >>211 >>203のapplyfは、特定のロジックに依存しない汎用的な関数だけど、 こういうものの定義や使用も認めないってことは ライブラリによる拡張も否定するってことでOK？ ライブラリを使わないと外部イテレータが使えないRubyをdisってるの？ 223 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 14:05:13.26 ID:ZLG0O37u.net] >>210 書かれてない要素を勝手に追加するから オレオレ定義って言われるんだよ クロージャの定義には無名関数であることも、文が書けるor書けないことも、 含まれてないんたから、勝手に条件に追加すんな 224 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 14:39:36.41 ID:1EyzOdES.net] >>220 >>219 はPythonのlambdaからでも副作用を伴うメソッド呼べますよってコードだな 225 名前：名無しさん＠そうだ選挙に行こう mailto:sage [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 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 20:39:14.11 ID:HrrHquek.net] >>225 本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。 first-class valueってのは、変数に代入したり、関数の引数に渡したり、 関数の値として返したりできるオブジェクトの事だよ。 def だの lambda だのっていうのはそういうオブジェクトであるクロージャを作り出すための構文だよ。 pythonは手続き型言語だっていうけど、そんなの当たり前だろw rubyだのjavascriptだのだって手続型言語だよ。 227 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 21:42:39.17 ID:gzcIElev.net] >>226 > 本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。 その意味であれば、関数型言語と Ruby/JavaScript だと 関数定義よりもクロージャのほうがが本質的だね プリミティブな名前とクロージャから関数(or メソッド)が作られるという 因果関係があるのだから ただし、Python だけは違うみたいだね > rubyだのjavascriptだのだって手続型言語だよ。 外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている だから最初から関数型言語と同等なクロージャを備えて誕生した それが知られるようになったのは最近だから、知らない人は多いけどね..... 手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ 　peace.2ch.net/test/read.cgi/tech/1409526637/857 -- > パクリどころか Ruby と JavaScript は、これらの作者自身が > Lisp を基礎として言語を設計したと語っている > > ・Lisp から Ruby への設計ステップ > 　yohshiy.blog.fc2.com/blog-entry-250.html > ・JavaScript: The World's Most Misunderstood Programming Language > 　www.crockford.com/javascript/javascript.html > （邦訳版「JavaScriptの勉強：世界で最も誤解されたプログラミング言語」へのリンクは閉鎖） > > だから関数型プログラミングという土俵の上で Ruby や JavaScript に > 手続き型言語の Python がいくら挑戦しても勝てずに負け続けているのは、 > しごく当然な結果なわけ 228 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 22:07:55.30 ID:HrrHquek.net] ＞外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている S式で表現されてなきゃlispじゃねえよ。 229 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 22:14:57.19 ID:HrrHquek.net] だいたいlispが関数型言語だって言うことにも抵抗がある。 230 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 23:06:18.71 ID:gzcIElev.net] >>227 >手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ 自己レスで補足する（すべての手続き型言語が Python と同じではない.... 同じ手続き型言語に関数型の特性を追加した言語でも、 調べた範囲だと少なくとも Perl5/Java8/C++11 のクロージャは ・>>4,>>121 のクロージャ定義に沿って設計され、 ・クロージャ内で任意の文が書ける ただしそれら言語がクロージャをサポートした時期は遅かった 真面目に設計したからだろう 対して Python の関数型サポートは素早かったけど、検討が不十分だったと言うほかない リリース後に改善要望/議論紛糾したあげく、結論を出せず現在に到る(>>199) 231 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/13(土) 23:27:26.05 ID:fdPKe7oz.net] 横だけど、 Rubyのブロックはラムダじゃないしファーストクラスでもないよね ？ メソッドにラムダを渡すこともできるけど、不格好なんだが？ これって、ここのオレオレ定義にてらすとどうなの？ なんだか、ラムダに文を書けない（書かない）ようにしている Pythonの仕様をあげつらうためだけにオレオレ定義をこねくって 悦に入ってるPythonアンチがいるって感じがするだけなんだが。 232 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 00:01:22.20 ID:Gw1grNBM.net] Rubyのブロックの中に副作用をジャンジャン書いて それを繋げるスタイルを関数型と言われても困るわ 文推奨の時点で関数型とは言い難いわけだし 233 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 00:38:38.65 ID:iRnVJ1/v.net] オレオレクロージャ君は言葉が通じないし、 必死でググった的外れで糞長い引用でしか反応しないし、 相手するだけ無駄。 234 名前：デフォルトの名無しさん mailto:sage [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 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/14(日) 10:29:16.99 ID:63H3dBz7.net] オレオレクロージャ君って少し前に某スレでPython disってた人にそっくり 236 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/14(日) 14:05:17.21 ID:2A/iPobJ.net] lambda ラ…ランバダ… 237 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/14(日) 14:52:29.83 ID:VBy2GaOL.net] >>236 もっと勇気をもって！ ランバダ！ 238 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/14(日) 15:49:06.80 ID:hNeAViIY.net] 　　　　　　　,-----、 　　　　　　/　　　　 ヽ. 　　　　　　|　(･)　(･) | 　　／ヽ￣　　　　　　￣ﾉヽ 　/　　 ヽ＿＿＿＿＿/　　ヽ 　|　　　/　　　　ｌ　　　|　　　 |＼ 　|　　　|　　。ノ　ヽ。 .|＿＿_|　 ＼ 　ヽ＿__ヽ　　　 +　　 ﾉ,､_､_､_ヽ　　＼ 　　|　　ヽ|￣￣￣￣ |　;;;;;;;;;;;;;;;＼＿ ﾉ 　< ````/＼ 　　　 ／＼;;;;;;;;;;;;;;;;;/ 　　ヽ;;;;;;|　　＼＿/　　　ヽ;;;;;;;;;;;ﾉ 　　　￣.|＿__/ 　　＼＿＿)￣ 　 .＿＿__ 　　　　/　　 |　　　 　|　　 |　　　　＼　／ 　　　（＿＿_|　　　 　|＿＿）＝＝＝⊃ 　　　　　　勇者の父　ランバダ 239 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2014/12/14(日) 15:54:41.51 ID:KqwrXZGg.net] 無駄にMP消費していざという時に足りなくなって犬死にする無能 240 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 21:10:51.70 ID:Gw1grNBM.net] >>240 後から言い逃れようとしても、掲示板にはログが残ってるから無駄ですよ >>99に対する>>103の返答の時点で、何も分かってなかったのは明らか 242 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 21:42:31.25 ID:k3gK/GUJ.net] >>240 RubyのブロックはProcクラスのインスタンスではないよ ブロックそのものは、メソッド呼び出し文法の一部でしかない そのブロックを、それのみで値として扱うためのラッパがProc 243 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 21:59:53.72 ID:Y1wljoB2.net] Rubyistは全員クロージャを間違った解釈してるのか？ それとも、奴だけなのか？ そこが気になるな。 244 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 22:03:54.59 ID:lkA9lgpO.net] >>232 残念ながら Ruby の関数型プログラミングというスタイルは、 全世界の Ruby コミュニティですでに認知されている ・Functional programming with Ruby 　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 　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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 22:59:19.75 ID:iRnVJ1/v.net] もうみんなgaucheに改宗しようぜ 247 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 23:42:14.32 ID:NejhiS1a.net] gaucheいいよね 249 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 23:49:27.85 ID:lkA9lgpO.net] >>241 つまり「Ruby のブロックはクロージャである」という初歩的なミスについて、 >>103 をレスした時点から数えて >>231 が指摘するまでの間には 誰一人気付けなかった事実が「掲示板にはログが残ってるから明らか」になるわけですね た い へ ん わ か り や す い で す 250 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 23:57:54.55 ID:pRYhwT4i.net] 最近はほぼgaucheでしかプログラム書いてない。 もう止められない体になってしまった。。。 251 名前：デフォルトの名無しさん mailto:sage [2014/12/14(日) 23:58:44.82 ID:iRnVJ1/v.net] 俺、numpyとscipyとopencvのサポートがgaucheにくっ付いたら、python捨てるんだ！(遠い目 252 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 00:02:02.47 ID:wtT+wvpm.net] common lisp処理系の方が速いのあるしライブラリも充実してるし良いよ 253 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 00:07:51.10 ID:G9R+2lJx.net] ループしないで全部再帰で書きたい 254 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 00:08:50.51 ID:YlFhPVoF.net] lisp-2なのが何となく嫌 255 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 00:31:53.12 ID:K7E8QpHY.net] >>253 いいよ 256 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 08:42:12.40 ID:J0ddkTzC.net] >>249 だってRubyなんてマイナー言語どうでも良いし？ 257 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 20:13:34.89 ID:AoWRRy2d.net] >>244 > また Ruby の「ブロック付きメソッド呼び出し」とそれらを並べる(=チェーンさせる)スタイルは、 > Apple の新言語である Swift にそのまま採用された Obj-C が inline Smalltalk が書ける C なのに、Swift が Ruby をまねたみたいなデマはやめてくれる？ それと、 Ruby で関数型スタイルのプログラムを書けるということを、Ruby で書いたら関数型プログラムになるかのように書くのもやめてくれる？ 259 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 21:18:41.61 ID:QjagSoag.net] 主観を事実であるかのように語る客観性の無さ オレオレ定義の根拠を問われて自身の過去の書き込みを引用するコミュニケーション不全 完全に論破されると、自分の間違った主張を相手が言い出したと歴史歪曲しようとする卑怯さ 全てを兼ね備えると>>244みたいな奴になる 260 名前：デフォルトの名無しさん mailto:sage [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 　magazine.rubyist.net/?0009-Legwork このためループ処理でもないのにイテレータ(iterator, 反復子)という用語は紛らわしいという声が挙り、 用語「イテレータ呼び出し」は「ブロック付きメソッド呼び出し」へと名称が「後から変更された」 つまり単に用語の命名が「後から」改められだけで、言語仕様の基本は「最初から」何も変わっていないはずです >RubyはOOPLとして設計され、それが主で関数型プログラミングは結果として付いてきた スマンが、いいかげん説明は面倒なので以下を読んでください ・Lisp から Ruby への設計ステップ 　yohshiy.blog.fc2.com/blog-entry-250.html ただし、もともとメソッド lambda は proc の別名で同じ意味でしたが、 1.8 の時代に lambda の挙動が変更されメソッドとして独立しました その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません 言語仕様として「関数型プログラミング向けに後から追加/変更」されたのは、自分の記憶だとコレくらいしかありません 261 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 22:40:54.50 ID:G9R+2lJx.net] 俺が平安時代に読んだ本だと、iteratorはアイテレータって書かれてたな。 あとhierarchyはハイアラーキだった。 262 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 22:46:59.52 ID:G9R+2lJx.net] そんなにlispに憧れてるなら、lispを使えばいいのに。 263 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 22:47:19.92 ID:BuhXHDiL.net] > 1.8 の時代に lambda の挙動が変更されメソッドとして独立しました > その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません RubyのProc.newで作られるオブジェクトは returnの挙動が普通の関数と違ってキモすぎるので lambdaの方だけでも普通に直したんでしょう 264 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 23:02:52.91 ID:BuhXHDiL.net] さらに言えば、Rubyのブロック変数のスコープの扱いが1.9で仕様変更されてるけど、 それについてmatz自身が > それは、Rubyが最初から関数型言語としてスタートしてないからであって、言語が違うからですよね。 と語っているね www.atmarkit.co.jp/news/200907/24/ruby.html 265 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/15(月) 23:24:28.86 ID:eMlPsgxM.net] >>263 おそらくその通りだと思います >>264 もしも Matz が Lisper ではなく Schemer であったなら、 違った結果になっていたかもしれませんね 267 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 00:31:08.98 ID:IiuX/rSM.net] 自己レスになりますが、>>245 では： > （Python だけでなく、この「お題(>>191)」は Ruby であっても再帰を使えば同じく分かりにくいコードになる） とカキコしました で、後から考え直して「手続き型のループ＆破壊的代入」ではなく、しかも「関数再帰」も使わずに、 参照透明性がある関数型プログラミングのコードを考えてみました 　ideone.com/UrfbuL ポイントは「反復に組み込みメソッド loop」を「ブロック脱出に引数付のbreak文」を使った２点です なおメソッド loop は一般に loop do .... end という手続き型のスタイルで書かれることが多いために ループ構文の一種と誤解されがちですが、（lambda を構文糖であると >>257 が 勘違いしたように....） loop はメソッドですので(コードで示したように) inject へチェーンさせることができます また「参照透明性はあっても、手続き型の制御構造であるbreak文の利用は反則ではないか？」という 指摘を予測して、 同じスタイルで(break文の代わりに)組み込みメソッド catch と throw を使ったコードも書きました 　ideone.com/SaCAFi ただし、この catch/throw は大域脱出のために用意されたメソッドですから、 今回の「お題」のように単一ブロックを脱出するだけならbreak文を使うのが素直だと考えます ついでに(catch/throw の代わりに)Scheme 由来の継続(continuation)を使ったコードも書きました 　ideone.com/5t1VEq 268 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 02:54:32.21 ID:178msYck.net] こんな無駄に遠回しなコード沢山書いてどんだけオナニー好きなんだよ。 269 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 02:58:06.18 ID:178msYck.net] >>200の爪の垢でも煎じて飲めよ。 270 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 07:18:26.71 ID:/LiRSDzk.net] >>260 もちろん、本当はただのメソッドであってlambdaは文法要素ではない あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、その対比としてそう書いたまでだよ 分かりにくかったね、「構文糖のような存在のメソッド」と修正しておくよ 271 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 07:24:54.85 ID:/LiRSDzk.net] まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら 「真のクロージャ」って用語もおかしいのだと気付いて欲しいな 272 名前：1 mailto:sage [2014/12/16(火) 07:48:21.23 ID:PApLEh59.net] なんか知らんけど伸びてて嬉しいです 目標はGCスレ超えです 273 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 08:02:21.01 ID:/LiRSDzk.net] 一応lambdaというメソッドの実装された時期について調べてみたら、結構昔から存在自体はしてたのね 元々procと同じなのに字数多い&Procなのにlambdaって覚えにくいのと1.4当時は関数型とか知らんかったからスルーしてたのかな そこは俺の記憶違いだったわ 274 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 08:45:33.81 ID:7mh816Ug.net] クロージャがなければ参照カウント型のGCで済むんじゃないか説があるし ワンチャンあるよ 275 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 08:47:53.04 ID:7mh816Ug.net] 構文糖衣とかいいながら ラムダって名前から甘そうな印象をうけない 名前が悪いよ考え直すべき 276 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 08:56:24.06 ID:7mh816Ug.net] クロージャって名前も固いし 意味わかんねえから 貝殻のclamを頑張ってもじって クリームって名前にするくらいの 努力はあってよかった 277 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 09:58:24.78 ID:/LiRSDzk.net] >>275 そういう意味ではfunctionを名前ありの関数にもラムダにも使ったJavaScriptは上手いと思う らむだ何ソレ？な人にも「関数名書かないで使うと無名の関数も作れるよ」って説明で事足りるもんね 278 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 10:58:59.39 ID:gf3D6lb/.net] ブロックとProc.newとprocとlambdaと->があるRubyはやり過ぎ 279 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 11:12:47.94 ID:/LiRSDzk.net] >>278 まあ、Rubyは他の組み込みライブラリでも エイリアスや似たようなメソッド、所属モジュールが違う同様のメソッドとか持つのは普通だからね 俺は昔からproc派、RubyのProcとλ算法は別物だと思うからあの挙動でいいし、早く書けるし 280 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2014/12/16(火) 23:35:24.13 ID:178msYck.net] 関数型言語のクロージャと非関数型言語のクロージャはナニが違うですか。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef