[過去ログ] 次世代言語11[Rust Swift TypeScript Dart] (1002レス)
上下前次1-新
抽出解除 レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
847(4): デフォルトの名無しさん [] 2018/07/01(日) 01:54:08 ID:5prQoZWD(1/8) AAS
>>845845(2): デフォルトの名無しさん [sage] 2018/06/30(土) 23:39:42 ID:xV+Shhkx(1) AAS
>Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。
クロージャ「だから」、クロージャを囲む関数から戻る??
まるでクロージャだったら当然の挙動と言わんばかりの書き方だけど、クロージャってそんなんだっけ?
ヒント:Smalltalk
850(1): デフォルトの名無しさん [sage] 2018/07/01(日) 02:52:24.35 ID:QlwNZjji(1/5) AAS
>>847
関数型でもないウンコ言語がクロージャの話に入ってくんな
何の参考にもならんわ
864(1): デフォルトの名無しさん [sage] 2018/07/01(日) 10:59:11.30 ID:uHA6sqOS(1) AAS
>>844844(6): デフォルトの名無しさん [sage] 2018/06/30(土) 23:16:50 ID:tr0WXiW5(2/2) AAS
>>837
Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。
一方ラムダは、単にクロージャを抜けるだけ。
Groovy なども参照
def f
(0..5).each do |i|
puts i
return if i == 3
end
end
f() #=> 0, 1, 2, 3
はクロージャなら当然あるべき姿としてRubyのProcを語ってるからなぁ
それに対して>>847がヒント:Smalltalkって言ってるのは
要するにSmalltalkがクロージャのあるべき姿を体現してるって言ってるワケで、そりゃ傲慢すぎる
ただの一例としてSmalltalkのような仕様もあるって言うなら批判されないのに
870(1): デフォルトの名無しさん [sage] 2018/07/01(日) 11:43:42.24 ID:fENDu7uP(1/3) AAS
Smalltalkの仕様がどうであれ、それがRubyの仕様を正当化すると思ってなされているレス(>>847だの>>867867(2): デフォルトの名無しさん [sage] 2018/07/01(日) 11:16:48.58 ID:5prQoZWD(5/8) AAS
>>864
妄想が激しいね。
ヒント:Smalltalkっていうのは、Rubyのそのヘンテコな仕様はSmalltalk由来だということなんだけど。
お大事にね
だの)は
結局Smalltalkの仕様に権威がある、またはRubyがSmalltalkを模倣するだけの理由があるのを前提にしているわけで
傲慢という批判は妥当に思うな
899: デフォルトの名無しさん [sage] 2018/07/01(日) 20:00:26.61 ID:e+fGbKAY(2/2) AAS
>>862862(3): デフォルトの名無しさん [] 2018/07/01(日) 10:45:16.40 ID:QlwNZjji(2/5) AAS
Smalltalkの人たちはScalaやRustのtraitsに対して、オリジナルのSmalltalkと違うからダメだ!あれは別物!って批判するくせに
他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れっておかしくね?
ダブスタも甚だしいだろ
> 他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れ
私はSmalltalk信者wですが、この文脈での>>844の「クロージャだから」もそれを受けた>>847の「ヒント:Smalltalk」も
混乱を招きかねない説明やサジェスチョンだと思いまよ。
# 以下は比較的に古典的かつナイーブな実装の Squeak や Pharo を想定しています。為念。
Ruby の retrun に相当する Smalltalk の(唯一の)制御構造である「^戻り値」は、
Ruby の>>837837(4): デフォルトの名無しさん [sage] 2018/06/30(土) 16:41:24 ID:oxrLiD+S(1) AAS
るびぃ信者、Proc.new、ラムダ、ブロックにおけるreturn、break、nextの挙動の違いをまとめようとした模様
外部リンク:qiita.com
結果、ややこしすぎるためコーディングを工夫してreturnやbreakの使用を避けましょうというなんじゃそりゃな結論www
何か理由があってわざわざ挙動を変えたんだろうが(まさか行き当たりばったりってことはないよね笑)ややこしすぎで使用自体を避けられてちゃ本末転倒だよなwww
の例では prco_return や block_retrun と同じ挙動になります。
Object compile: 'rubyReturn
| f ret |
f := [:n | ^ n * 10. "以降に処理を書くとコンパイル時エラー"].
ret := #(1 2 3) collect: f.
^''ret: '', ret printString'.
self rubyReturn "=> 10 "
余談ですが、lambda_return の挙動も「thisContext retrun」(戻り値が欲しいときは「return: 戻り値」)
という表現を使えばまあできなくはないです(が普通はやりません)。
Object compile: 'rubyLambdaReturn
| f ret |
f := [:n | thisContext return: n * 10. #以降の処理は無視].
ret := #(1 2 3) collect: f.
^''ret: '', ret printString'.
self rubyLambdaReturn "=> 'ret: #(10 20 30)' "
いずれにせよ、Smalltalk でクロージャ内のリターンがそのクロージャを実行中のメソッドコンテキストを抜けるという挙動をもって
(継続渡しとかならともかく)Ruby の複雑な状況の説明を試みるのはあまりよい方法ではないのは確かですね。
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.038s