.NET上のPython処理系IronPythonがとうとう公開された。 オレゴン州ポートランドで開催中のOSCON 2004にあわせての公開らしい。
で、さっそくソースを読んでみるが、大変読みにくい。 C#に慣れてないってのもあるけど、 C#のリフレクションとIronPythonのリフレクションとが渾然一体となっていて 区別が付けにくいのがつらいところだ。
どうやら、メソッドは生成したILのコードをdelegateとして保持しておいて、 それを直接呼び出しているらしい。だから、メソッド呼び出しは、
という手順のようだ。確かに呼び出しにはリフレクションを使っていないが、 これで速いんだろうか。まあ、もともとのCPythonのセマンティクスも同じようなものなんで、 大丈夫なのかな。
そういえば、Jythonのソースは読んでないな(Java嫌い)。
LL Weekendが近づいているので、私の担当分Language Updateについてまとめようとするが、 今年(去年のLLから最近まで)は、言語仕様については進歩があんまりないことに気がついた。
一体、私はこの１年なにをしてたんだ(日記を書いてました)。
しかたがない、あと10日ほどの間にでっち上げるのはどうだろう。作者の強み。
国際化(M17N)の1.9への取り込み
どうせこの夏、論文に書くために、再実装＋1.9へのマージを予定していたので、前倒しする、とか。
メソッドコンビネーション
こっちは完全な新機能なので互換性の問題はない。が、効率の良い実装が大変なんだよねえ。 で、前田くんと議論したが...その結果は後で。
やっぱ無理があるかな。
というわけで、メソッドコンビネーションだ。
メソッドコンビネーションは、メソッドの前と後ろにフックをかけることを許すものだ。 CLOSで提供されている機能で、 一種のアスペクト指向と呼んでもよいかも。 というか、AspectJのGregor Kiczalesは元々CLOSのデザイナーでもあるから、 メソッドコンビネーションなどから発展してアスペクト指向が生まれたと言うべきだろうな。
これの効率の良い実装は難しい。 現在のRubyの実装を大きく変えないですむと嬉しい、という条件をつけるとなおさらだ。
思いついたのは(だれでも思いつきそうだが)、CLOSのメソッドコンビネーションが
という順序になっているのを、
という順序の変更を考えてみた。 CLOSとは確かに違うが、別にまったく同じであることにこだわるほど、CLOSに忠誠を誓っているわけではない。
とはいえ、primaryメソッドでsuperが呼ばれなければ、beforeメソッドやafterメソッドが一切呼ばれない点は、 嬉しくないこともあるだろう。すぐに考えついたのは、たとえばロギング機能をこれで実装しようとしたら、 includeでは(beforeメソッドなどは明示的にsuperを使わないと呼ばれないので)役に立たないと言う点だ。
これはincludeが(仮想的な)スーパークラスを追加するものだからいけないわけだ。 たとえばSatherのようなcode inlcusionであれば、同じレベルなので問題はない。 とはいえ、いまさらincludeの意味を変えるわけにはいかないので、 新しいオペレーション(かmoduleのような別物)を導入する必要があるなあ....。
などと、次々と考えが発散するのであった。でも、上記のアイディアはけっこう魅力的だなあ。 問題は「新しいオペレーション」の名前だな。ほんとはincludeが最適だと思うけど、 これは変えられそうにないし、「埋め込み」とかを意味する単語だといいのかな。
前田くんは「expand」を提案していた。include, extend, expand...、 うーん、一度慣れてしまえば、それなりにいいかも。
This work is licensed under a Creative Commons License.
＞ これで速いんだろうか。<br>Download presentation file<br>http://conferences.oreillynet.com/pub/w/29/track_python.html<br>ではグラフが出ています。<br>＞ 国際化(M17N)の1.9への取り込み<br>中国対応など期待してます。Rubyのソフトをインド・中国にオフショア開発発注<br>できる程度に。
とりあえず、UnicodeとSJIS/EUC/JISの相互変換が可能なモジュールは標準で添付して欲しいです。<br>PerlのEncodeモジュール級のモジュールが入るとうれしいな・・・<br>というのはわがままですかね^^;;
naruseさん、iconvなら標準添付されてますが...。<br>PerlのEncodeモジュールについては調べておきます。<br>ただ、すぐには無理でしょうね。<br><br>ＭＭＸさん<br>>中国対応など期待してます。<br><br>こういうのは実際に使う人の声を聞いておかないとろくなものはできませんから、期待している内容を具体的に聞いておきたいです。<br>オフショア開発発注に必要な程度の国際化とはどのようなものでしょう？
Encodeってiconv同様のテーブルを自前で持つって代物じゃありませんでしたっけ。<br>それはイヤだなぁ。
まつもとさん<br>>iconvなら標準添付されてますが...。 <br>確かにiconvは標準添付されていますが、実際にレンタルサーバーで使おうと思うと、使えないケースが多いのですよ。<br>とりあえず、さくらインターネットとmixedmediaではrequire 'iconv'ができませんでした。<br><br>なかださん<br>> Encodeってiconv同様のテーブルを自前で持つって代物じゃありませんでしたっけ。 <br>そうですね、Perl5.8の数割を一つのモジュールが占めるという、とんでもない代物です。<br>ただ、use encodingやuse openの便利さは魅力です。<br>http://www.lr.pi.titech.ac.jp/~abekawa/perl/perl_unicode.html<br>＃使い勝手がEncodeなら実装は裏でiconvを使ってもいいと思います。<br>＃いろいろな環境で動くのでしたら
iconv は機種依存性が高いのでいろいろと辛いのです。<br>iconv 関数の関数インターフェースについては標準化されているのですが、<br>iconv_open 関数に渡すコードセット名については全く標準が存在しません。<br>(多くの場合は MIME preferred name を受け付けてくれますが)<br><br>またスクリプト言語が一般に CGI でよく使われることによる宿命として、<br>SJIS がらみの問題に巻き込まれがちというところでしょうね。<br><br>そのあたりを考えると、iconv に頼るのではなく自前でコードセット変換を<br>持っている perl5.8 の選択というのは痛し痒しという感じでしょうね。<br>iconv と重複する大きなデータが必要になりますから。
Gaucheでも、iconvの互換性問題とSJISの0x5c問題に突き当たって、日本語分だけ自前で持つという、あんまり綺麗でない選択をしています。(ちょっと言い訳をすると、一応他の言語についてもiconvにオーバーレイして自前の変換を持てるようなアーキテクチャにはしてます。実装は日本語しかやってませんが)。SJIS問題に関してはcp932のエイリアスだとしてしまう方が真っ当なのでしょうね。<br>データの大きさに関しては、日本語分だけならそんなに大きくないです。文字コード推測・変換モジュール全体でdataセクションのサイズが108KBくらいです。
> SJIS問題に関してはcp932のエイリアスだとしてしまう方が真っ当なのでしょうね。<br><br>SJIS だけを cp932 のエイリアスにするという事は、混乱の<br>元だと思います。<br>Java で、一度、失敗していますね。<br>http://www.ingrid.org/java/i18n/encoding/shift_jis.html<br><br>こんなものがあります。<br><br>標準情報(TR) TR X 0015:1999<br>XML日本語プロファイル<br>XML Japanese Profile<br>http://www.y-adagio.com/public/standards/tr_xml_jpf/jpro.htm<br><br>Shift_JIS のエイリアスを cp932(Windows-31J) とするのであれば、次のようにする必要があると思います。<br><br>Shift_JIS → x-sjis-cp932 (Windows-31J/cp932/MS932)<br>EUC-JP → x-eucjp-open-19970715-ms (eucJP-ms)<br>ISO-2022-JP → x-iso2022jp-cp932<br><br>※注意: x-eucjp-open-19970715-ms ≠ Windows Code Page 51932