次世代言語11[Rust Swift TypeScript Dart]

**デフォルトの名無しさん** · 2018/06/03(日) 23:53:27.92

スレタイ以外の言語もok

前スレ
次世代言語10[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1524607347/

**デフォルトの名無しさん** · 2018/06/26(火) 23:00:40.71

可読性の高い綺麗なPerlコードを書けるものだけが石を投げなさい

**デフォルトの名無しさん** · 2018/06/26(火) 23:12:38.14

>>799みたいなのは設計当初は綺麗なんだけど
後から、例えばD言語のconst/immutableみたいな選択肢を追加してしまうと罠に化けそうじゃない？(妄想だけど)
その点元が冗長ならある程度耐性がある、という話。後から省略可能にする方はできるしな

**デフォルトの名無しさん** · 2018/06/26(火) 23:29:44.42

>>801
Dは全然知らないけど、調べたらデフォルトがミュータブルで、immutableをつけるとイミュータブルになるのか。

```
int x = 3; // ミュータブル
immutable int x = 3; // イミュータブル
auto s = "hello"; // イミュータブル
```

これはひどいな

**デフォルトの名無しさん** · 2018/06/26(火) 23:32:04.35

>>802
そこはまあしょうがないとして、イミュータブルにも種類があるという点に注目してくれ

**デフォルトの名無しさん** · 2018/06/26(火) 23:40:45.19

コンパイル時に値がわかるのが定数
実行時に初期化するがその後は変更しないのがimmutableかな

**デフォルトの名無しさん** · 2018/06/26(火) 23:56:28.51

加えて、現在のスコープからは変更不可能だが実体はミュータブルかもしれないのがconst
更にそれぞれに推移のON/OFFがある

何も書かないのがイミュータブルだとその内の1つを適当に使ってるということで
選択肢が増えたときにどれか1つが不自然に短く書けてたことになるし
現状を突き詰め直したときにコンテキスト毎に別のだったなんてことになると目も当てられない

**デフォルトの名無しさん** · 2018/06/27(水) 00:01:32.20

やっぱり言語仕様は頻繁に変えるべきということだな！w

**デフォルトの名無しさん** · 2018/06/27(水) 00:50:40.19

>>802
ゲェジかな
ワイの方がよっぽどいい設計できるわ
この作者はワイのケツ穴でも舐めてた方が幾分有益な人生になったんじゃないかｗ

**デフォルトの名無しさん** · 2018/06/27(水) 00:59:47.78

>>805
GCが必須ではない言語の場合、ミュータブルならばメモリ解放もできる

現在のスコープからは変更不可能だが実体はメモリ解放するかも
というのは非常にまずい
現在のスコープから変更不可能ならば実体も変更不可能にしたい

**デフォルトの名無しさん** · 2018/06/27(水) 01:19:45.86

>>808
それだとイミュータブルなオブジェクトを貰って何かする関数に
ミュータブルなオブジェクトを渡せなくならない？

そうすると print とか toString とか hash とか compare とかありとあらゆるものが
immutable / mutable 2種類必要になる
引数に2つオブジェクトがあると4種
3つなら8種

**デフォルトの名無しさん** · 2018/06/27(水) 20:24:28.42

ただの再代入不可な変数をイミュータブルって言い始めたのって何の言語からなの

**デフォルトの名無しさん** · 2018/06/27(水) 21:06:16.07

>>810
たぶん英語だと思う

**デフォルトの名無しさん** · 2018/06/28(木) 08:21:12.64

>>795
pythonなんかも細かいところはど汚いわけだがあんまりそういう汚いところ
触らんでも仕事になるって違いはある。
てかシンタックスなんててきとうにチェックでもそんな問題にならんよ。
self書かされることなんて文法で規制されてるわけでもないが問題になることなんてない。

**デフォルトの名無しさん** · 2018/06/29(金) 09:12:05.44

>>810
変更可、不可という概念は別に変数に限った話じゃない

**デフォルトの名無しさん** · 2018/06/29(金) 09:23:47.61

Pythonの型アノテーション試してるけど正直苦痛
TypeScriptを使ってるときには全く感じなかった無駄なもの書かされてる感がすごい
というかTypeScriptの統合が完璧すぎるんだな
型書くことはノイズになるどころかコードをむしろ美しくするとすら思えるもんな

**デフォルトの名無しさん** · 2018/06/29(金) 10:57:44.57

少しでも欲を出せばそうなる
完璧な無欲か完璧な満足かの1bitしかない
HaskellやRustのようになるまで止まらないぞ

**デフォルトの名無しさん** · 2018/06/29(金) 11:15:41.22

>>814
Python 3.6の変数アノテーションはTypeScriptと大して変わらないのでは？
以前のコメント形式は糞だったけど

**デフォルトの名無しさん** · 2018/06/29(金) 13:13:42.11

>>814
全部の変数にアノテーション付けようとしてる？
基本、関数・メソッドの入出力だけでいいぞ
残りは大体推測してくれる

**デフォルトの名無しさん** · 2018/06/29(金) 13:43:06.77

>>817
ライブラリなどの既存メソッドの戻り値はほとんど型なしだから結局オレオレ型宣言を左辺の変数に付けて回ることになる

**デフォルトの名無しさん** · 2018/06/29(金) 15:55:24.38

>>818
あー、過渡期だからそれはあるかもね
対策としては、他モジュールを呼び出すところはなるべく集める、いきなり完璧を目指さないぐらいか

**デフォルトの名無しさん** · 2018/06/29(金) 20:05:29.68

そんなに型に気を使って消耗する位ならもう生js使おう
適当にラッパーかけとけラッパー

**デフォルトの名無しさん** · 2018/06/29(金) 21:06:52.59

>>820

TypeScriptユーザーがシコシコ型定義ファイル作ってるおかげで、vscodeでjsでも補完きくんやで。感謝せーや

**デフォルトの名無しさん** · 2018/06/29(金) 21:09:19.97

せめて同梱の標準ライブラリくらいは網羅しておいてほしいよね。

**デフォルトの名無しさん** · 2018/06/29(金) 21:11:52.89

>>814
typeScriptみたく型定義ファイルの共有する仕組み無いの？
いちいち書くのはしんどいな。

**デフォルトの名無しさん** · 2018/06/29(金) 21:39:48.60

>>823
しんどいのか
その作業がないということはライブラリの作者は楽をしている
だからライブラリが増やすのも楽
そういう仕組みなんだろう

**デフォルトの名無しさん** · 2018/06/29(金) 22:21:57.95

>>824
TypeScriptの場合は型定義を提供することでTypeScriptユーザーに使ってもらいやすくなり、
ユーザーの増加がライブラリ製作者にとって一手間かけるモチベーションになる
Pythonの場合は型アノテーションを付けたらPython3.5以上でしか使えなくなるのでユーザーは確実に減る
結果、誰も対応しない
根本的に破綻してるんだよ

**デフォルトの名無しさん** · 2018/06/29(金) 22:35:49.90

>>825
破綻してるのはお前のマウンティングだよ
マウントが酷いのはHaskellで、TypeScriptは無関係みたいなイメージが根本的に壊れた

**デフォルトの名無しさん** · 2018/06/29(金) 22:39:04.05

そんなんでイメージ変わるのかよ…

**デフォルトの名無しさん** · 2018/06/29(金) 23:18:51.02

おれ的にはこのまま型定義ファイルがすべてのライブラリに標準装備されて緩やかにjsがts化していくことを希望したい。
最初から型定義がライブラリに入っていること多くなってきたよな、

**デフォルトの名無しさん** · 2018/06/29(金) 23:54:19.04

>>828
それには同意

**デフォルトの名無しさん** · 2018/06/30(土) 02:42:20.84

このスレに来て初めてマウンティングって言葉を知ったわ。

**デフォルトの名無しさん** · 2018/06/30(土) 03:36:46.79

>>823
あるよ。
typeshedてのがそれ

>>825
関数の引数、返値なら3.0から書けるし、コメント使うか別ファイルに書くやり方なら2.7にも対応可能ですが

**デフォルトの名無しさん** · 2018/06/30(土) 08:02:10.37

Haxe では型定義ファイルがあるから、型推論も入力補完もできる

**デフォルトの名無しさん** · 2018/06/30(土) 09:44:21.50

通常ならライブラリ本体丸ごと読んで型を調べるべきだ
本体に型がないなら別ファイルに書く

**デフォルトの名無しさん** · 2018/06/30(土) 12:26:26.59

>>831
なんだあるんだ。なら型付言語として使われるのも時間の問題だな。
rubyにもあるみたいだし、
ライブラリのインターフェースだけでも型付き当たり前の世界が来そうだね

**デフォルトの名無しさん** · 2018/06/30(土) 14:15:03.20

まーたruby信者のそ、そんなのる、るびぃでもできるし！か。呆れ
なんでもかんでも深く考えず流行りをそうやって後付けで増築してって奇形極まってるよね。二度と使わないよ。

**デフォルトの名無しさん** · 2018/06/30(土) 15:58:28.61

rubyの違法建築感は否定しない
が、なんかまとめ臭い書き方だなおい
5chエアプか？

**デフォルトの名無しさん** · 2018/06/30(土) 16:41:24.65

るびぃ信者、Proc.new、ラムダ、ブロックにおけるreturn、break、nextの挙動の違いをまとめようとした模様
https://qiita.com/jnchito/items/83410c0cda446efea582

結果、ややこしすぎるためコーディングを工夫してreturnやbreakの使用を避けましょうというなんじゃそりゃな結論ｗｗｗ

何か理由があってわざわざ挙動を変えたんだろうが(まさか行き当たりばったりってことはないよね笑)ややこしすぎで使用自体を避けられてちゃ本末転倒だよなｗｗｗ

**デフォルトの名無しさん** · 2018/06/30(土) 17:39:57.19

>>836
その人はrustがコンパイルできないおじさんだからほっときなさい

**デフォルトの名無しさん** · 2018/06/30(土) 18:00:17.99

rust
ruby
似てないこともないな

**デフォルトの名無しさん** · 2018/06/30(土) 18:59:53.28

>>834,836
とはいえ、ruby にまともに使える型チェックの実装があるのかには興味あるな。
まえ調べた感じだと、教祖の型チェック周りの発言はフワッフワだし、実装してみたい個人が互換性のない「オレオレ型チェック」を作っては破棄してる感じで、万人が使えるものは何一つないようなんだが。

**デフォルトの名無しさん** · 2018/06/30(土) 19:02:48.17

どうせ
if type(...) != my_class:
とかのシュガーだろ。そんなもんに目くじら立てても意味あるのかね。

**デフォルトの名無しさん** · 2018/06/30(土) 19:33:21.11

Rubyはオモチャだから型付けなんて要りません
それより散らかったオモチャを片付けなさい

**デフォルトの名無しさん** · 2018/06/30(土) 20:38:08.56

自分のために違法建築したとは考えにくい
ユーザーを忖度して違法建築なら利己的ではないからOKという風潮があったんじゃないか

会ったこともないユーザーをモチベーションにするのはやめてほしい

**デフォルトの名無しさん** · 2018/06/30(土) 23:16:50.81

>>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

**デフォルトの名無しさん** · 2018/06/30(土) 23:39:42.18

＞Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。

クロージャ「だから」、クロージャを囲む関数から戻る？？

まるでクロージャだったら当然の挙動と言わんばかりの書き方だけど、クロージャってそんなんだっけ？

**デフォルトの名無しさん** · 2018/07/01(日) 00:39:17.02

そんなものちゃんと読んでる>>845に感心したw
ネットにはゴミが多いね

**デフォルトの名無しさん** · 2018/07/01(日) 01:54:08.61

>>845
ヒント：Smalltalk

**844** · 2018/07/01(日) 02:00:27.83

クロージャは、クロージャの外側の環境をつかんでいる。
つまり、クロージャを囲む関数内の変数をつかんでいる

だから、クロージャ内でreturn すれば、外側の関数も抜けて、
関数内の変数なども、解放した方が良いと考えた

Groovy の挙動とは違うかも

**デフォルトの名無しさん** · 2018/07/01(日) 02:11:27.56

>>848
return だけだったら納得できるんだが、next や break の扱いがぐちゃぐちゃなのはどう説明するの?

**デフォルトの名無しさん** · 2018/07/01(日) 02:52:24.35

>>847
関数型でもないウンコ言語がクロージャの話に入ってくんな
何の参考にもならんわ

**デフォルトの名無しさん** · 2018/07/01(日) 03:04:39.74

>>837
> まさか行き当たりばったりってことはないよね笑

その、まさかだぞ。
楽しくプログラミング（）した結果が仕様だ文句あるか！ｗ

**844** · 2018/07/01(日) 08:32:31.95

クロージャ(block)内のbreak は、クロージャを抜けるだけで、外側の関数は抜けない。
関数の最後まで実行される

クロージャ内のnext は、次の繰り返しに進むだけで、クロージャも抜けない。
クロージャの最後まで実行される

def f
num = 0
(0..5).each do |i|
num = i
break if i == 3
end
puts num
end

f() #=> 3

**デフォルトの名無しさん** · 2018/07/01(日) 08:58:20.58

すみませんがゴミの話は当該スレでお願いします

**デフォルトの名無しさん** · 2018/07/01(日) 09:01:20.31

これ他の言語にも影響あるだろ
continueはバグの原因になるとか、gotoの方がマシとか言われる

**デフォルトの名無しさん** · 2018/07/01(日) 09:18:30.80

>>850
えー？closureが関数型特有な概念だと思ってるわけー？
面白いね、それ。本当は純粋関数型ではclosureはさほど重要ではないのだけど。
どうしてclosureが関数型固有な概念だと思ったのか、説明してごらん？

**デフォルトの名無しさん** · 2018/07/01(日) 09:22:52.78

>>855
おまえが自分で説明しないで人に説明させようとするからだよ
もし関数型の人が説明したら関数型の概念になるに決まってるだろ

**デフォルトの名無しさん** · 2018/07/01(日) 09:23:49.76

>>852
あなたが closure だからと主張する、block は 952の挙動だが Proc では break は例外吐くらしいけど何で?

# 言っちゃ悪いが、closure は定義した時点での環境を基準に動作が普通だと思うんで、
# ループ外で定義されているならば next/break は一律例外吐くで無いと一貫性がないようにしか見えん。

**デフォルトの名無しさん** · 2018/07/01(日) 09:24:49.31

>>857
すまん、「block は >>852の挙動」だな。

**デフォルトの名無しさん** · 2018/07/01(日) 09:25:25.69

このbreakとnextは並列コレクションで困る気はする

**デフォルトの名無しさん** · 2018/07/01(日) 10:22:00.59

>>856
へー、技術のベースになる概念が、関数型の人が説明したら別物になるのかー
おもしろいねークスクス

**デフォルトの名無しさん** · 2018/07/01(日) 10:23:24.47

>>856
で、関数型の人って誰？ばか？

**デフォルトの名無しさん** · 2018/07/01(日) 10:45:16.40

Smalltalkの人たちはScalaやRustのtraitsに対して、オリジナルのSmalltalkと違うからダメだ！あれは別物！って批判するくせに
他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れっておかしくね？
ダブスタも甚だしいだろ

**デフォルトの名無しさん** · 2018/07/01(日) 10:48:49.50

忖度とか伝言ゲームとかいう問題を織り込むまでがITです

**デフォルトの名無しさん** · 2018/07/01(日) 10:59:11.30

>>844はクロージャなら当然あるべき姿としてRubyのProcを語ってるからなぁ

それに対して>>847がヒント：Smalltalkって言ってるのは
要するにSmalltalkがクロージャのあるべき姿を体現してるって言ってるワケで、そりゃ傲慢すぎる

ただの一例としてSmalltalkのような仕様もあるって言うなら批判されないのに

**デフォルトの名無しさん** · 2018/07/01(日) 11:00:03.93

クロージャの方が自身の関数スコープを持ってる印象だな
メジャーな中では Java, C#, C++, JavaScript, Obj-C, Swift などがそうだし
Rubyのラムダも上記と概ね同じに見える

ブロックは文字通りコードの塊と考えるとreturnやbreakについて妥当な動きに見える

Proc.newは挙動がキモい

↓によるとdo…endも挙動が違うらしいから >>837 のリンク先は4種で比較した方がいいかもな
https://qiita.com/riocampos/items/43e4431ddff93e01a18d

**デフォルトの名無しさん** · 2018/07/01(日) 11:08:34.39

中身読んだら結合度の差だったので >>865 の最後2行は撤回する

**デフォルトの名無しさん** · 2018/07/01(日) 11:16:48.58

>>864
妄想が激しいね。
ヒント：Smalltalkっていうのは、Rubyのそのヘンテコな仕様はSmalltalk由来だということなんだけど。
お大事にね

**デフォルトの名無しさん** · 2018/07/01(日) 11:19:42.69

>>862
きみ、結局はSmalltalkでのクロージャからのreturnの仕様を調べることすらしないで
思い込みだけで騒いでるでしょ？
そういうのを「バカ」って言うんだよ

**857** · 2018/07/01(日) 11:25:18.69

>>867
smalltalkには break や continue (next) はないだろう？
ruby のは、closure に break や next を持ち込んでおかしくなっているように見えるよ。

**デフォルトの名無しさん** · 2018/07/01(日) 11:43:42.24

Smalltalkの仕様がどうであれ、それがRubyの仕様を正当化すると思ってなされているレス(>>847だの>>867だの)は
結局Smalltalkの仕様に権威がある、またはRubyがSmalltalkを模倣するだけの理由があるのを前提にしているわけで
傲慢という批判は妥当に思うな

**デフォルトの名無しさん** · 2018/07/01(日) 11:52:10.11

気持ち悪い挙動だと言いがかりをつける気満々のレスに対して
smalltalk でもそうだった昔からある挙動ですよと指摘しているだけでは。

なにも知らなければ議論はできない
といって smalltalk の知識は前提にしていいのかは疑問
とはいえやはり共通の知識がないと議論は無理だし難しいわ

**デフォルトの名無しさん** · 2018/07/01(日) 12:46:18.88

Smalltalkを前提にすることに意味はない(Rubyと周辺状況が違いすぎるのに何故真似た？)というのが
すぐ直前の議論では

**デフォルトの名無しさん** · 2018/07/01(日) 12:59:23.83

俺を批判するのはSmalltalkを批判するのと同じだっていうことの意味は一応ある
自分自身を守るためではなく仲間を守るためという大義名分ができる

**デフォルトの名無しさん** · 2018/07/01(日) 13:03:25.38

滅びた言語のヘンテコな機能を真似た言語が
やっぱりヘンテコになって滅びつつある
それだけの話ではある

**デフォルトの名無しさん** · 2018/07/01(日) 13:04:20.30

もうRubyの話はやめよう
次世代でも現世代でもないし

**デフォルトの名無しさん** · 2018/07/01(日) 13:25:35.07

なんで？
rubyは触ってないけど、rubykaigiとかで盛り上がってる様子見てると、楽しそうだし盛り上がってる感あるけど。未だ現役じゃないの？
スタートアップがrails採用するイメージって、まだ古くないよね？
最近だとrailsのボトルネック部分をgoで書く話が面白かった。

**デフォルトの名無しさん** · 2018/07/01(日) 13:42:13.57

perlの後継になりそこなったし
海外の人気がかなり落ちてるからね
rails用言語で終わってしまった感

**デフォルトの名無しさん** · 2018/07/01(日) 13:43:43.18

railsにincludedされてるバッテリーだろ？ｗｗｗ

**デフォルトの名無しさん** · 2018/07/01(日) 13:57:23.22

つーかrails言語で別に良くないか？
言語なんて所詮はツールなんだから。
bashでwebサービス作るやつはいないだろ？

**デフォルトの名無しさん** · 2018/07/01(日) 14:06:40.12

目的と結果を比較されるから
目的はこれだったのに結果はこれなのか？と

目的などどうでもいいと断言できる人は少ない

**デフォルトの名無しさん** · 2018/07/01(日) 15:32:54.19

>>870
そこまで妄想が激しいようだと治療は困難だね。
でもあきらめないで、先生からもらった薬をちゃんと飲むようにね。
でないと他人様に迷惑かけることになるから。
やくそくだよ。

**デフォルトの名無しさん** · 2018/07/01(日) 15:34:06.79

薬？お薬の幻覚でも見えてんのか？

**デフォルトの名無しさん** · 2018/07/01(日) 15:40:22.85

Smalltalkという完全に終わった言語に執着してるんだから
まあフツーに頭がおかしいんでしょう
薬飲めも普段自分が言われてるんだろうね

**デフォルトの名無しさん** · 2018/07/01(日) 15:55:04.17

自分が言われたら嫌なことを人に言うって奴かｗ

**デフォルトの名無しさん** · 2018/07/01(日) 16:07:47.75

ここでも見てとれるようにRubyは言語と言うより信者がクソ。
他言語のスレで聞いてもないのにルビーデワールビーデワー宣伝必死過ぎてウザい。
Ruby自体は悪くない。

**デフォルトの名無しさん** · 2018/07/01(日) 16:15:05.64

>>885
同感

**デフォルトの名無しさん** · 2018/07/01(日) 16:33:48.43

陰謀論みたいに、お前が世界を支配してるんだろって言われるのは嫌じゃないが

**デフォルトの名無しさん** · 2018/07/01(日) 17:13:50.39

>>873
今回のSmalltalkは道連れ的に名前出されただけでむしろ被害者
変なのが混ざってないSmalltalk内ではちゃんと一貫した挙動のはずだろ？知らんけど

**デフォルトの名無しさん** · 2018/07/01(日) 17:30:42.04

>>885
よくわからんのだけど
Rubyでは～って意見が出たらそんなに嫌なん？ｗ
俺なら他の言語でどうって意見はむしろ感心があるが

**デフォルトの名無しさん** · 2018/07/01(日) 17:32:52.47

>>889
同感

**デフォルトの名無しさん** · 2018/07/01(日) 17:49:59.60

>>883
Smalltalkを知っている != Smalltalk信者
ちゃんとお薬のんでる？
勝手にやめちゃいけないよ？

**857** · 2018/07/01(日) 18:07:48.02

>>891
なあ、smalltalk と ruby に詳しいんだったら、意味の無い罵倒を止めて、 >>869 の答えてくれない?

**デフォルトの名無しさん** · 2018/07/01(日) 18:22:04.92

Perlさん何で死んでもうたん？

**デフォルトの名無しさん** · 2018/07/01(日) 18:23:52.18

Perlはワンライナーとして生き残ったのさ

**デフォルトの名無しさん** · 2018/07/01(日) 19:07:07.35

>>891
まあお前がSmalltalk信者かどうかは見た人間が判断するから気にするな。病気が進行するぞ

ただ客観的な事実としてSmalltalkは完全なオワコンw
このスレでは場違いすぎて引くレベル

**デフォルトの名無しさん** · 2018/07/01(日) 19:34:13.12

>>894
わかる。awkよりも使い勝手はいい。正規表現処理ツールとして有り。ふとnode.jsでもいい気がしたけど

**デフォルトの名無しさん** · 2018/07/01(日) 19:46:03.96

スレタイ読まずに書き込んでる奴らなんなの？

**デフォルトの名無しさん** · 2018/07/01(日) 19:51:05.54

>>862
> Smalltalkの人たちはScalaやRustのtraitsに対して、オリジナルのSmalltalkと違うからダメだ！あれは別物！って批判する

それは「批判」ではなく、理解や運用の混乱を避けるための「区別」の必要性を訴えているのです。
「オブジェクト指向」もそうで、Smalltalkが重きを置く「決定の遅延のためのメッセージングのオブジェクト指向」と
C++以降の「抽象データ型をクラス（またはそれに準ずるエンティティ）で実現するオブジェクト指向」とは区別すべきと一緒です。

批判があるとすればそれは、本質的に違うものに後から同じ名前を付けて混乱を招いていることに対するものでしょうね。

**デフォルトの名無しさん** · 2018/07/01(日) 20:00:26.61

>>862
> 他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れ

私はSmalltalk信者ｗですが、この文脈での>>844の「クロージャだから」もそれを受けた>>847の「ヒント：Smalltalk」も
混乱を招きかねない説明やサジェスチョンだと思いまよ。

# 以下は比較的に古典的かつナイーブな実装の Squeak や Pharo を想定しています。為念。

Ruby の retrun に相当する Smalltalk の（唯一の）制御構造である「^戻り値」は、
Ruby の>>837の例では 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 の複雑な状況の説明を試みるのはあまりよい方法ではないのは確かですね。