6 月 10 日 パネルディスカッション「Ruby 2.0」

初日のパネルディスカッションは、Ruby の未来 (がそもそもあるのかないのか) を語る時間です。 Ruby 2.0 は、過去の Ruby と非互換になる、といわれます。しかし、それは変化の目的ではなくて結果でしょう。 ここで、Ruby 2.0 で起こる変化の「目的」が明かされることでしょう。

パネル企画「Ruby 2.0」

時間

13:15〜14:15

司会

高橋征義氏

• 実装寄り度 ★★★
• 実現度 ★★
• とにかく 1.9.1 リリース宣言度 ★★★★
• アッカーマン関数度 ★★
• エンコーディングサポートの鬼度 ★★
• 開発者と対決度 ★★
• 分業話度 ★★★
• 内輪暴露度 ★★★
• 重鎮 eban さんの発言度 -

パネリスト・コメンテータ紹介

パネリスト

卜部さん、小迫さん、まつもとさん、ささださん

コメンテータ

青木さん、中田さん、中村 (う) さん、やまださん、わたなべさん、助田さん

壇上と最前列とで円座しています。

講演資料 (まつもと)

基調講演の講演資料に同梱されています。

講演資料 (ささだ)

http://www.atdot.net/~ko1/tmp/RubyKaigi2006Panel2_0sasada.pdf

講演資料 (小迫)

http://www.geocities.jp/kosako3/oniguruma/resource/JRC2006_panel.pdf

講演資料 (卜部)

http://jp.rubyist.net/RubyKaigi2006/?c=plugin;plugin=attach_download;p=program0610;file_name=RubyKaigi2006PanelRuby2.0Urabe.pdf

パネリスト発言

まつもとゆきひろ氏「Ruby 2.0 の世界」

真実

「Ruby 2.0 とは燃料である。」との見解が出されました。「我々は止まってはいられない。」(サメですか¹)

本質

Ruby 2.0 は、Ruby を再デザインして、再実装して、「これまでの後悔をつぶしたもの」であると定義されました。

ポリシー

Ruby は Ruby のままでありつづけることを強調されました。互換性を考慮して、多くのソースはそのまま動く「……と、いいなぁ」とのことです。注意点として、優れたデザインと互換性が矛盾する時は、優れたデザインを採る、との方針が示されました。

特徴

文法上の特徴として「互換性がない」「スコープが変わる」「多値 (多くの値があるときどうなるか？非常に‘タチ’の悪い問題) の扱いの変更」などが挙げられました。http://www.eigenclass.org/ という有用なサイトが紹介されました²。

とはいうものの

2.0 の話が出てから来年で 10 年になるのだそうです。しかしこのままでは、リリースが 2010 年になるやら 2020 年になるやら分からない様子です。

この懸念は以前から各地で表明されており、Rubyist Magazine のパロディ版でも 2073 年までの予想が提示 されていますが、その頃に今の開発者の何人が生き残っているでしょうか……。

いつ出るか分からないので、それまでのつなぎに、と妥協案が提起されました。

妥協案

Ruby 1.9.1 リリース、2007 Xmas。決心しました。1.8 保守は継続されます。

version rule

1.9.1 は安定「志向」版です。基本的に 3 桁表記ですが、致命的なセキュリティ問題へのパッチを含んだ版などに対して 4 ケタ目を使うようになるかもしれない、とのことです。このとき teeny を小数あつかいにするようです (例: 1.8.4.2 であれば 4.2)。

1.9.1 に入るもの

今、1.9 にあるもの

ローカル変数の新しいスコープ規則³

M17N⁴

YARV (希望); このときに入らないと 3000 年 YARV リリースとか

入らないもの

new GC (論文も reject されたし)

classbox (仕様決まらないし) ⁵

selector namespace (これも仕様が見えない)

キーワード引数 ⁶

メソッド結合

課題

「2.0 でいいじゃん」といわれる (でしょうね) と「一理ある」とのことです。

ということで 2.0 というより 1.9.1 の話になりました。

C1 (助田さん)

Win32OLE ではキーワード引数を扱わざるを得ない。Visual Basic (VB) の世界だとキーワード引数があって、今は Ruby 側で Hash を用意して VB と対応させているが、本来どうしたらいいんだろう？ 2010 年までは待てない。

A1

Windows は鬼門だが、Ruby の新言語仕様は、その辺の情報も参考にしたい。ただ来年 Xmas には間に合わないだろう。API 支援はしたいので、色々教えてください。

C2 (中村(う)さん)

1.8 と 1.9 で、とくに何が違うの？

A2

細かいことが多い。鬼車とか。クラス変数が継承しなくなった。クラス定数スコープ。BasicObject⁷ は今朝入れた。あとは……。

Q3 (Yugui さん)

ブロック引数の構文⁸は？

A3 (まつもとさん)

-> は残ってる。入れる気満々なんだけど。

C3 (中田さん)

-> は見た目が……。

A3 (まつもとさん)

きっと 10 年後にはみんな僕に感謝してるんだよ。

ささだこういち氏「YARV」

YARV (Yet Another Ruby VM) は「世界一速い Ruby 処理系」を目指して開発されている仮想マシンです。計算モデルとしてはスタックマシン⁹を採用しています。次世代 Ruby 処理系として公式に採用されることを狙いつつ開発されていますおり、情報処理推進機構の 2004 年度および 2005 年度上期の未踏ソフトウェア創造事業¹⁰として採択され、「皆様の血税により開発できた」とのことです。

現在の Ruby 処理系はソースコードを解析して構築した Abstract Syntax Tree を逐次辿りながら実行しています。これが遅くなっている原因なので、YARV ではソースコードをバイトコードにコンパイルし、バイトコードをスタックマシン上で実行します。コンパイル時の各種最適化にもかなり力を入れているそうです。

YARV の開発は、現在までに次を達成したということです。

• Ruby 本体とのマージ (開発リポジトリは別となっています)
• POSIX Thread 及び Win32 Thread を利用したネイティブスレッドへの対応。

JIT コンパイラ¹¹や AOT コンパイラ¹²の実装は視野には入れているものの、現状では「今後の課題」ということです。Ruby 1.9 に変更が入るとそれに追随しなければならないので、「敵はまつもとさん」だそうです。

各種ベンチマークも提示されました。アッカーマン関数の計算では他の言語処理系や Ruby 1.9 と比較しても YARV の性能は圧倒的で「アッカーマン関数を計算するには YARV」とアピールしていました¹³。代表的なアプリケーションを用いたもう少し現実なベンチマークもありましたが、tDiary では今の Ruby より遅くなったりしており今後の改善が望まれます¹⁴。

そのほか、今後の課題として次が示されました。

• ファイル名や API 名から “yarv” を取る。これからは YARV ではなく “The Ruby VM” となるのだから。
• 1.9, 2.0 の変更に追随していく。
• Ruby 本体は CVS で管理されているが、YARV は Subversion。Ruby への統合を進めるためにまず CVS を覚える。
• JIT, AOT コンパイラの実装

C1 (青木さん)

JavaVM, .NET VM そういうのじゃいけないの？

A1

いいんじゃないんでしょうか。ではなくて、セマンティックスにギャップがあるので、Ruby の仕様を満足する VM を実装することには十分意味がある。また、既存のほかの VM を利用するとなると、今まで世界中で作成された膨大な拡張ライブラリを捨てることになってしまう。¹⁵。

C2 (中村(う)さん)

何のために Native Thread に対応しなきゃいけないのか？

A2

以前聞いた話なんですけど。システムコールなどでブロックされてしまうケースを回避したいから。

C2 (中村(う)さん)

マルチ CPU でスレッドが並列実行されて早くなったりするか？

A2

こんなこともあろうかと(→スライド)。いまの実装は 1 つの CPU で動くモデルになっている。順次スケーラブルな実装にしていきたい。

小迫清美氏「正規表現ライブラリ」

開発の動機

1. 勘違い。従来の Ruby では、GPL の正規表現エンジンが使われているが、そのことがデュアルライセンス化を招いて、その上それが GPL 違反だと思い込んでしまい、正規表現エンジンの代替物があれば問題を解決できると思ったから。
2. 正規表現が難しい。もしかしたら実装してみたら分かるようになるんじゃないか？

特徴

• 30 種類のエンコーディングをサポートしている。
• Named Group (グループ化したパターンに名前をつけられる)
• Subexp call (パターンの一部分を別の場所から共有できるようにする)

課題

• Unicode のサポート向上。
  • 大文字/小文字を区別しないマッチをより広いコード領域で行えるようにする。現状では 0xFF までの範囲しか、大文字-小文字の対応関係を認識していない。
  • Character Property/Block/Script に対応
  • これらは、M17N が出るまで様子見か。
• RCR237 (?{var=}…) グループのキャプチャ結果を直接ローカル変数に代入できるようにする。¹⁶

C1 (やまださん)

RCR237 の機能を Ruby に取り込もうとする具体的な動きはあるのか？

A1

なんにもしてない。要求が高くなればやるかも。

C2 (青木さん)

速度は？

A2

きかれると思ったので (→スライド)。¹⁷¹⁸

(高) 2.5.5 > 1.8regex > 4.1.0 (35%ほど現状より遅い) > PCRE (低)

卜部昌平氏「リリースエンジニアリング」

リリースエンジニアリング

ずばり申し上げて白紙。NameError。

開発の進展 (のなさ)

• [ruby-list:2462] 1997-03-28
• [ruby-dev:5192] 1999-09-27
• YARPC 19101
• [ruby-talk:20324]
• [ruby-talk:41360]

Q (卜部さん)

やる気あんのか？

A (まつもとさん)

なにかは出るんじゃないんですかね？

Q (卜部さん)

たとえば

A (まつもとさん)

今年中にはなにか。

N (卜部さん)

やる気はあると。

C0 (中田さん)

うーーー、ん。

C1 (中村(う)さん)

プレゼンで、ぐるっと回るのはどうやってるの？ (卜部さんに)

A1 (卜部さん)

XGL (Xの拡張) です。もう (一番言いたいことはしゃべったので) どうでもいいや。

コメントと質疑応答

コメンテータから

• なかむら (う) 氏
• わたなべひろふみ氏
• やまだあきら氏
• 青木峰郎氏
• 中田伸悦氏
• 助田雅紀氏

との自由討論。

ここで司会の高橋さんの手書きレジュメが活躍したことを付記します。

Q1 (中村(う)さん)

YARV にはユーザレベルスレッドは無いので MS-DOS のようにネイティブスレッドの無い環境ではスレッドが動かなくなる。DOS は、今後ずっとサポートされないの？

A1 (ささださん)

YARV は、逆に言うとネイティブスレッドのみになります。DOS 対応、ユーザレベルスレッドの対応は priority が低いです。将来的にサポートするかどうかも決めていない。

Q2 (中田さん)

YARV か YARV じゃないのかが選択できるようにならないの？

A2 (ささださん)

(YARV 無しは) 1.8 使ってください (笑)。

Q2 (中田さん)

configure でできるように、と。

A2 (ささださん)

configure で 1.8 と切り替えるわけじゃないですよね (笑)、と。内部の実装を YARV 向きにとっかえる話になるので、「選ぶ」というのはありえない。もう戻れない道です。

Q3 (青木さん)

mod_ruby では各ウェブアプリケーションで別々の VM で動かしたい時とかあるので、multi VM ¹⁹ができるようにならないか？

A3 (ささだ)

そういうブランチを作ってはいます。未踏事業で (実装する、と言ってしまったテーマに含めていたために) 一応実装はしましたが、効率まだあまり考えてないです。将来、2030 年とか 2010 年には使えたらいーなー、とか。

Q4 (青木さん)

コード隠したい人に対して対応は？

A4 (ささださん)

Java でいう class ファイルみたいものにする仕組みは、すでにある。しかし、それを簡単に使えるようにするのは priority の低い話。誰かに頼まれればやるけど。

Q4 (まつもとさん)

いくらでやります？

A4 (ささださん)

応相談。

N4 (まつもとさん)

ではのちほど。

Q5 (やまださん)

今後の添付ライブラリの方針は？ 整理の話、rubygems²⁰ 標準化、class 命名規則、CPAN などにある規約のようなもの、枠組み。

A5 (まつもとさん)

問題が起きていないのなら今のままでいいのでは。厳しくするつもりはない。ただ推奨ルールの類は明文化したほうがいいかもしれない。

• 明らかに機能がかぶっているライブラリは削除したい。
  • cgi-lib はもう消そう。
  • ftools と fileutils も重複。
  • getopt なんとか……。
• gems は標準添付化される方向に進む。1.8 のときは標準添付が実現せず、今後の見通しも不透明。1.9.1 でなんとかするかもしれないが、gems の連中とは話がなかなか通じなくてね。
  • ただ rpa-base と比べて rubygems の方が現実的かなあ、とか。時間あるので、なんとかなるといいなあ。

Q6 (中村(う)さん)

(gems のマージは) 時期的には？

A6 (まつもとさん)

……間に合わすかどうかはこっちの決める話ではない。

事前に意見お寄せいただいた中から

Q1

Ruby on Rails の中の ActiveSupport の機能のいくつかを吟味して標準に取り入れて欲しい。

A1 (まつもとさん)

(それらの機能が) 悪いとは言わないが、だからといって汎用言語にこれはどうか、というものもあり。こちらからこう変えろと口出しはしない。小出しに要望 (RCR) にしてもらって、ひとつずつ議論していくのがよい。どれが欲しいかどんどん教えて欲しい。

• symbol#to_proc とか？ あれはけっこういいのでは？ (1.9 には 6/11 に入った。)
• DHH: in_groups_of なんかはどうか？

["1","2","3","4","5"].in_groups_of(3)||

…これは each_slice(3) ？ そのもの？

["1","2","3","4","5"].in_groups_of(3){|x| p x}

は

["1", "2", "3"]
["4", "5", nil]

になるけど、

["1","2","3","4","5"].each_slice(3){|x| p x}

は

["1", "2", "3"]
["4", "5"]

になる。末尾がちょっと違う結果になる。 多重代入を使って {|a,b,c| p c} や {|x|a,b,c=x; p c} のようにすれば結局 in_groups_of と each_slice はまったく同じ結果になるし、 in_groups_of は元々 nil が入っていた場合と勝手に nil が追加された場合を区別出来ないから in_groups_of は不要。

Q2

多値が導入されるらしいけど、今までとの違い・概念がよくわからない。入門のポインタがあると嬉しい。

A2 (まつもとさん)

えーーっと、まぁ、あの、99.8% のユーザには関係ないので²¹……だめですか？ 影響がないわけではないが、説明しても理解を期待できないし、ユーザにとっても聞きたくないだろうから。今朝 (6/10) のコミットの仕様が matz からの提案。多値は配列で表現しよう。

会場からの質問・意見

Q1 (田中(akr)さん)

2038 年問題²² (2036 年問題ではない) への対応は？

A1 (まつもとさん)

プラットフォームに任せます。いざとなったらそれなりに対応。ふなばさんの date4 もリリースされたことだし。

Q2 (大林さん)

末尾再帰の最適化をしてほしい。

A2 (ささださん)

じつはコードは YARV にちょっと入ってたりします。Ruby の文法で末尾再帰の最適化は不可能 なんですが、末尾呼び出しの最適化はやってみました。だけど、あまり速度向上はありませんでした。Scheme を実装してみたいので、実装はしているという感じです。

Q3 (Yugui さん)

YARV で Scheme を動かすならなおのこと継続²³ (が必要) ですよ。継続かわいいですよ継続。

A3 (ささださん)

今の YARV には実装されてないです。下手に実装すると誰かが core を吐かせるので。

Q4 (MoonWolf さん)

YARV コードの中で動いている機械語を直接ユーザが扱うことはできる？ ブロックをコンパイルしたものをネットワーク上でやりとりさせるとか？

A4 (ささださん)

YARV のコードのシリアライズ化は、すぐできる。命令列を Array にするものはあるので、そうすれば Array から YAML にでも何にでも変換可能なので、送ることはできると思います。ただし、そこで問題になるのは、環境を含めたオブジェクト (クロージャ) で環境をどうやって引き連れていくかということで、それについてはいいアイデアがありません。

Q5 (永井さん)

今後、拡張ライブラリが YARV の上で動くようになると思うが、C で拡張ライブラリを書く場合に、どのようなところに注意したらよいか？

A5 (ささださん)

現在の C API はほとんど使えるようになっている。ごく一部、使えなくなった API があったり、より効率の良い新しい API が提供されたりしている。

パネリストの言い残し

まつもとさん

やる気ありますから。

ささださん

これで出さないわけにはいかないし。

卜部さん

YARV・鬼車にはものがあるから、まだいい。リリースエンジニアリングはモノがない。ので「まつもとさん頑張ってください」という圧力をこれからもかけ続けていきますのでよろしくお願いします。

まとめ

• 2.0 の実体はありません
• やる気はあります
• Ruby 1.9.1 が来年クリスマスに (は) 出ます