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

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

パネル企画「Ruby 2.0」

時間
13:15〜14:15
司会
高橋征義氏 s06100046.jpg sRubyKaigi2006_067.jpg
  • 実装寄り度 ★★★
  • 実現度 ★★
  • とにかく 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 とは燃料である。」との見解が出されました。「我々は止まってはいられない。」(サメですか1)
本質
Ruby 2.0 は、Ruby を再デザインして、再実装して、「これまでの後悔をつぶしたもの」であると定義されました。
ポリシー
Ruby は Ruby のままでありつづけることを強調されました。互換性を考慮して、多くのソースはそのまま動く「……と、いいなぁ」とのことです。注意点として、優れたデザインと互換性が矛盾する時は、優れたデザインを採る、との方針が示されました。
特徴
文法上の特徴として「互換性がない」「スコープが変わる」「多値 (多くの値があるときどうなるか?非常に‘タチ’の悪い問題) の扱いの変更」などが挙げられました。http://www.eigenclass.org/ という有用なサイトが紹介されました2
とはいうものの
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 にあるもの
ローカル変数の新しいスコープ規則3
M17N4
YARV (希望); このときに入らないと 3000 年 YARV リリースとか
入らないもの
new GC (論文も reject されたし)
classbox (仕様決まらないし) 5
selector namespace (これも仕様が見えない)
キーワード引数 6
メソッド結合
課題
「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
細かいことが多い。鬼車とか。クラス変数が継承しなくなった。クラス定数スコープ。BasicObject7 は今朝入れた。あとは……。
Q3 (Yugui さん)
ブロック引数の構文8は?
A3 (まつもとさん)
-> は残ってる。入れる気満々なんだけど。
C3 (中田さん)
-> は見た目が……。
A3 (まつもとさん)
きっと 10 年後にはみんな僕に感謝してるんだよ。

ささだこういち氏「YARV」

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

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

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

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

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

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

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

  • ファイル名や 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 を利用するとなると、今まで世界中で作成された膨大な拡張ライブラリを捨てることになってしまう。15
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=}…) グループのキャプチャ結果を直接ローカル変数に代入できるようにする。16
C1 (やまださん)
RCR237 の機能を Ruby に取り込もうとする具体的な動きはあるのか?
A1
なんにもしてない。要求が高くなればやるかも。
C2 (青木さん)
速度は?
A2
きかれると思ったので (→スライド)。1718
(高) 2.5.5 > 1.8regex > 4.1.0 (35%ほど現状より遅い) > PCRE (低)

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

リリースエンジニアリング
ずばり申し上げて白紙。NameError。
開発の進展 (のなさ)
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 19ができるようにならないか?
A3 (ささだ)
そういうブランチを作ってはいます。未踏事業で (実装する、と言ってしまったテーマに含めていたために) 一応実装はしましたが、効率まだあまり考えてないです。将来、2030 年とか 2010 年には使えたらいーなー、とか。
Q4 (青木さん)
コード隠したい人に対して対応は?
A4 (ささださん)
Java でいう class ファイルみたいものにする仕組みは、すでにある。しかし、それを簡単に使えるようにするのは priority の低い話。誰かに頼まれればやるけど。
Q4 (まつもとさん)
いくらでやります?
A4 (ささださん)
応相談。
N4 (まつもとさん)
ではのちほど。
Q5 (やまださん)
今後の添付ライブラリの方針は? 整理の話、rubygems20 標準化、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% のユーザには関係ないので21……だめですか? 影響がないわけではないが、説明しても理解を期待できないし、ユーザにとっても聞きたくないだろうから。今朝 (6/10) のコミットの仕様が matz からの提案。多値は配列で表現しよう。

会場からの質問・意見

Q1 (田中(akr)さん)
2038 年問題22 (2036 年問題ではない) への対応は?
A1 (まつもとさん)
プラットフォームに任せます。いざとなったらそれなりに対応。ふなばさんの date4 もリリースされたことだし。
Q2 (大林さん)
末尾再帰の最適化をしてほしい。
A2 (ささださん)
じつはコードは YARV にちょっと入ってたりします。Ruby の文法で末尾再帰の最適化は不可能 なんですが、末尾呼び出しの最適化はやってみました。だけど、あまり速度向上はありませんでした。Scheme を実装してみたいので、実装はしているという感じです。
Q3 (Yugui さん)
YARV で Scheme を動かすならなおのこと継続23 (が必要) ですよ。継続かわいいですよ継続。
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 が来年クリスマスに (は) 出ます

  1. サメなどの原始的な魚類はエラに自力で水を送り込む仕組みがないので、泳ぎ続けることで水流の中にいるようにしないと窒息してしまいます 

  2. eigenclass.org の著者は「特異クラス」の英訳は “singleton class” ではなく “eigenclass” であるべきだと主張しているそうです。 

  3. ブロックローカル変数の新しいスコープ規則: 現状の Ruby ではブロック引数とブロック外の変数が同名だと書き換えてしまう等の問題がある。 

  4. M17N: Multilingualization の略で、複数の異なる言語を同時に扱うための枠組み。Ruby M17N では文字列オブジェクトが自分のエンコーディングを「知っている」ようになり、内部エンコーディングは決め打ちされないようです。 

  5. Classbox: スコープを限定してクラスの書き換えを許す仕組み。http://www.rubyist.net/~matz/20060104.html#p01 

  6. キーワード引数 (keyword arguments): メソッド呼び出し時に、引数の順番を気にせず、引数に名前 (キーワード) を付けて呼び出す方法。 

  7. Object クラスより上位の、Kernel モジュールを include していないクラス。http://www.rubyist.net/~matz/20050406.html#p02 

  8. 一時期検討されていた Perl6 風の lambda 構文 

  9. スタックマシン: Intel x86 CPU のようにレジスタ上の値に対して演算するのではなく、スタック上に積まれた値を演算する計算機。Java VM や .NET の CLR はスタックマシンとして実装されている。) 

  10. 未踏ソフトウェア創造事業: 経済産業省の外郭団体である独立行政法人情報処理推進機構の事業で、情報産業の基盤づくりとして独創的な技術や才能の発掘・支援を目的としている。 

  11. JIT コンパイラ: Just In Time コンパイラ。仮想マシンのバイトコードを実行時にネイティブコードにコンパイルして動作の高速化を図る仕組み。Java VM 用の JIT コンパイラとしては Sun の HotSpot 技術などがある。プログラムのうち良く使われる部分だけを選択的にコンパイルしたり、プログラム実行時の統計的情報を利用した最適化を施したりできるという利点がある。 

  12. AOT コンパイラ: Ahead Of Time コンパイラ。バイトコードを事前にネイティブコードなどに変換しておく仕組み。JIT に比べて実行時にコンパイル時間を掛けなくて済むという利点があるが、コンパイル後のコードが大きくなったり、実行時統計情報は利用しづらいという欠点もある。 

  13. アッカーマン関数なんて誰もつかわないって 

  14. ささだ注:具体的には、リフレクション関係のチューニングが出来ていない 

  15. ささだ注:あと、やっぱり自分で作ったほうが面白いよね 

  16. RCR: Ruby Change Request の略。RCRchive というサイトに Ruby への機能拡張・変更要求としてまとめられている。英語。 

  17. PCRE: Perl Compatible Regular Expressions の略。その名の通り Perl 互換の正規表現ライブラリ。 

  18. UTF-16 対応で遅くなった 

  19. 同一プロセスで複数のVMを動かすこと 

  20. rubygems: Ruby のライブラリやアプリケーションを集めたリポジトリである RubyGems を利用するためのツールの名前。ネットワーク越しに Ruby ライブラリの検索、インストール、更新、削除などを行う。RubyGems は Ruby on Rails がホストされていたので注目を浴びた。 

  21. [ruby-dev:28712] によると言いたかったのは「99% は説明されても理解しない (したくない) し、聞きたくないと思う」 

  22. 2038 年問題: 時刻を表すために 1970 年 1 月 1 日午前 0 時からの経過秒数を 32bit 符号つき整数で数えている場合、2038 年 1 月 19 日午前 3 時 14 分 8 秒に桁が溢れてプログラムが時刻を誤認する問題。 

  23. http://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=Continuation