Feature #2080: Proc#to_source, Method#to_source

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.6

[yugui (Yuki Sonoda)]

=begin
[ruby-core:24673]に見るように、Proc#to_sourceやMethod#to_sourceがあると、1.8時代にnode.hを利用してしまっていたようなライブラリの問題の多くを解決できます。そこでnodeやiseqに元のソースコードを持たせておいて、必要に応じてiseqから取得することを提案します。

一般的にはコードは処理データに比べて十分に小さいので、メモリ所要量の増加は許容範囲ではないでしょうか。

例:
proc = ->(x, y) {
x + y
}
proc.to_source #=> "x + y"
=end

[ko1 (Koichi Sasada)]

=begin
　ささだです。

Yuki Sonoda wrote::

担当者: Koichi Sasada, カテゴリ: core, Target version: 1.9.2

[ruby-core:24673]に見るように、Proc#to_sourceやMethod#to_sourceがあると、1.8時代にnode.hを利用してしまっていたようなライブラリの問題の多くを解決できます。そこでnodeやiseqに元のソースコードを持たせておいて、必要に応じてiseqから取得することを提案します。

一般的にはコードは処理データに比べて十分に小さいので、メモリ所要量の増加は許容範囲ではないでしょうか。

　私も便利だと思うんですが、ちょっと便利すぎだし、仕様の検討も、凄く自由
度のあるわりに議論が十分ではないので 1.9.3 を目指して議論するといいと思
うんですが、どうでしょうか（つまり、2ヶ月で収束するとは思えません）。

　便利そうだから、みんな喜んで使うと思うんですが、喜んで使うと思うので、
やっぱり仕様変更、っていったときギャっという人は多いんではないかと思います。

　例えば、分からない点として、ぱっと次のような点が思いつきました。思いつ
いた順に書いてるので、仕様と実装の話が混じっています。

1. 引数は？
   1.1 オプショナル引数は？
2. C で書いたメソッドは？
3. ISeq#to_source じゃないの？
   3.1 ISeq は CRuby 固有じゃない？
4. 全てのメソッドの文字列表現をとっておくのは意外と大きいのではないか？
   たとえば、Rails だと数十MBものメモリをそれで消費しないか？
   4.1 圧縮する？
   4.2 ファイル名、ポジションだけ保存して、ファイルから読み込む？
   4.2.1 ファイルの変更があったらどうする？
   4.2.2 eval だったらどうする？
   4.2.3 実は、eval 部分だけ保存しておいて、あとはファイルからで
   十分だったりしない？　ファイルの日付も一緒に保存しておいて、
   日付が違ったらエラー or nil とか。うーん、使いづらいかな。
   4.3 必要な場合は、trace と同様に何か require したら、その後作成した
   iseq はソースを保存するようにするとか？　でも、Rails はまず使い
   そうだから、メモリ消費量に関する解決にはならないな。
   4.4 各文字列を VALUE にするとGC pressure が増えて嫌だなあ
   -> 別途管理？
   4.5 temp file 作っちゃう？　Ruby 起動するたびに数十MBのディスクを消費、
   嫌だなぁ。
5. どこまで返す？
   5.1 メソッド内メソッド定義は？
   5.2 というか、Proc 内のクラス定義、メソッド定義、ネストした Proc は？
6. コンパイラ
   6.1 事前コンパイラを作ったり作らなかったりしているんですが、
   その場合どうなるのかなぁ。
7. CRuby 以外はどうなんだろ。

--
// SASADA Koichi at atdot dot net

=end

[dohzya (Etienne Vallette d'Osia)]

=begin
An other way would be to create a spec to represent ruby code into s-expression.
Each interpreter transforms its internal representation into a standard s-expression,
so ruby gains a cool and powerful lisp feature.
Maybe a simple lib/gem could provide this feature to some of the existing interpretors (like ruby_parser for cruby 1.8).

It makes the file-pointing impossible (unless a temp file is created, containing only s-expressions)
but if it is possible to transform iseq to sexpr, it will makes the files-pointing useless.

Building source from sexpr is already done by some projects, so I suppose it's not a big deal.
=end

[yugui (Yuki Sonoda)]

=begin
2009年9月11日2:43 SASADA Koichi [e-mail]:

　私も便利だと思うんですが、ちょっと便利すぎだし、仕様の検討も、凄く自由
度のあるわりに議論が十分ではないので 1.9.3 を目指して議論するといいと思
うんですが、どうでしょうか（つまり、2ヶ月で収束するとは思えません）。

明らかに後から足しても困らないものではあるので、ゆっくり仕様を練りますか。

たとえば、Rails だと数十MBものメモリをそれで消費しないか？
については、笹田さんにだけはお話ししましたが起動オプションで

• 圧縮して持つ
• 持たない
  なども選べると良いのではないかと思います。

--
Yugui (Yuki Sonoda)
[e-mail]
http://yugui.jp

=end

[rogerdpack (Roger Pack)]

=begin
Note that you can "reget" source by using #source_location (except for dynamic methods).

Maybe an iseq "reverse compiler" would be helpful for dynamic methods [and/or instead of this]?

-r
=end

[mame (Yusuke Endoh)]

• Target version changed from 1.9.2 to 2.0.0

=begin
遠藤です。

　私も便利だと思うんですが、ちょっと便利すぎだし、仕様の検討も、凄く自由
度のあるわりに議論が十分ではないので 1.9.3 を目指して議論するといいと思
うんですが、どうでしょうか（つまり、2ヶ月で収束するとは思えません）。

1.9.2 には入らない、ということで、Target version を変更します。

1.9.2 will not include this feature.
This ticket just remains for further discussion to aim to include
this feature in 1.9.3 or later.

--
Yusuke Endoh [e-mail]
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

=begin

=end

[rogerdpack (Roger Pack)]

Still looking forward to this feature request :)

[ko1 (Koichi Sasada)]

• Description updated (diff)
• Assignee changed from ko1 (Koichi Sasada) to matz (Yukihiro Matsumoto)

この件，まつもとさんは何かご意見はありますか？

[mame (Yusuke Endoh)]

• Target version changed from 2.0.0 to 2.6

[riffraff (gabriele renzi)]

any hope to finally see this?

[matz (Yukihiro Matsumoto)]

• Status changed from Assigned to Rejected

Use source_location.

Matz.