Onion開発日記

_ [ジョギング]3km

走るのは、約１週間ぶりだ。今日は、弟が走りたいというので、 一緒に走った。

_ [ジョギング]3km

今日も弟と一緒に走った。最近は、さすがにかなり暖かくなってきたので、走り終えると、結構汗をかくようになった。

_ [Onion]FAQ

まだ処理系自体を公開していないのにFAQも何もあったもんじゃないが、とりあえず、FAQ(のようなもの)を公開。

_ [Onion]プロジェクト申請

そろそろOnionを公開しようかということで、SourceForge.jpにプロジェクト 申請を行った。

しかし、入力項目を書いて申請したのだが、申請を受け付けた旨のページが表示されなかったので、ちゃんと申請できたのかいまいちよくわからない。とりあえず１日待ってみて承認/却下通知が来なかったら、もう一度申請し直してみよう。

_ [Onion]プロジェクト申請２

今まで待っても通知が来なかったのでやはり申請ができてなかった可能性が高いと判断して、再びSourceForge.jpにプロジェクト申請を行った。すると、今度はちゃんと申請を受け付けた旨のページが表示された。やはり、昨日の時点では申請ができていなかったようだ。

_ [Onion]公開予定日

一応、今日が公開する予定の日だ。まだ全然ドキュメントが整備できてないし、実装もbuggyだが、とりあえず公開しないと始まらないと思うので、プロジェクト申請が通れば、すぐにでもOnionを公開しようと思う。

_ [Onion]公開

とりあえず公開しました。 ここから、ソースがダウンロードできます。まだまだ未実装の機能がたくさんあり、バグも多いですが、ご意見などいただけたら幸いです。

_ [Onion]承認

昨日出した、プロジェクトの申請が通った。とりあえず、今週中に、開発中のソースをCVSリポジトリに入れよう。CVSは、今まであまり使ったことが無いのでいろいろ勉強せねば。

_ [Onion]トップレベル

Java VMでは、全ての命令コードは最終的にはどこかのメソッドに属していなければならない。つまり、実行文(式文や制御構文など)が書いたのがトップレベルであっても、そのコンパイル結果は何かのメソッドに格納されなければならない。

では、トップレベルの実行文のコンパイル結果はどのメソッドに格納されるべきだろうか。まず思いつくのは、mainメソッドだ。これは、javaコマンドで実行されるのがmainメソッドであることを考えると妥当であるように思えるが、トップレベルからthisにアクセスできないのはやや不便であるように感じられる。

例えば、トップレベルにインスタンス変数を定義して、それにアクセスするといった使い方をしたいのだが、staticだとそれもできないだろう。static変数に自分のクラスのインスタンスを格納するなどすればできないことも無いが、いまいち美しく無い。

また、トップレベル上でトップレベルで定義したメソッド(以降、これを関数と呼ぶ)にアクセスできる必要があるため、トップレベルがstaticなら関数もstaticである必要がある(はず)。これは、メソッドがデフォルトでstaticでないことを考えると、あまり美しく無いので、避けたい。

他に考えられるのは、コンストラクタかインスタンスメソッドだ。これらについては、明日検討してみることにする。

_ [Onion]トップレベル２

次にコンストラクタについて考えてみる。トップレベルの呼び出しを、コンストラクタのコードにコンパイルすれば、インスタンスメソッドを呼び出すこともできる。コマンドライン引数をコンストラクタ引数で渡せば、トップレベルからコマンドライン引数にアクセスすることもできる。Javaで書くとこんな感じだろうか。

class TopLevel{
  TopLevel(String[] args){
    //ここにトップレベルの実行文がコンパイルされる
  }
  public static void main(String[] args){
    new TopLevel(args);
  }
}

インスタンスメソッド(例えばrunとする)にコンパイルする場合も、基本的には同じだ。引数としてコマンドライン引数をとるメソッドを作って、それを呼ぶようにすれば良い。例えば、こんな感じで。

class TopLevel{
  TopLevel(){
  }
  void run(String[] args){
    //ここにトップレベルの実行文がコンパイルされる
  }
  public static void main(String[] args){
    new TopLevel().run(args);
  }
}

どちらにしても、大差は無いし、問題も無いように見える。しかし、トップレベルが任意のクラスを継承できるようにしようとすると、問題が発生する。

スーパークラスのコンストラクタが無引数であれば良いが、スーパークラスに引数があるコンストラクタしか無い場合、そのコンストラクタをトップレベルのコンストラクタから呼び出さなければならない。

このとき、スーパークラスのコンストラクタに渡すべき値などは当然分かるわけもないので、引数の型のデフォルト値(intなら0、参照型ならnullなど)を入れることくらいしかできないだろう。そうなると、もうそのスクリプトは正常に動作するかどうかわからない。運が良ければ実行できるかもしれないが、運が悪ければ、スーパークラスのコンストラクタ内で例外が発生して、プログラムが終了してしまうかもしれない。

そうすると、トップレベルが任意のクラスを継承できるようにするなら、staticメソッドにコンパイルするしか無いと思えてくる。どうしたものか。

_ [Onion]CVS

Webページを参考にして、SourceForge.jpのCVSリポジトリにソースをインポートした。数十分で終わると思っていたのだが、EclipseのCVSの設定がよくわからず、数時間も費やしてしまった。

_ [その他]食事

弟と、今年度筑波大学に入って来たいとことその家族とで、つくばセンターの中華料理屋で食事。ここ数年全然会っていなかっただけあって、皆、随分記憶の中の印象と変わっていた。ともあれ、久しぶりに会った人と話すというのは、それだけでなかなか楽しいものだ。

_ [その他]買い物

食事後、弟と一緒に石丸電気とWonderGooを回って、書籍やパソコンなどを見て回る。立ち読みして良さそうだったので、プログラミング言語の概念と構造を購入。あと、以前にUSBメモリを紛失してそのままだったのを思い出して、新しいUSBメモリ(512MB)を購入した。

_ [書籍]プログラミング言語の概念と構造

まだパラパラと読んだ程度だが、内容としては、プログラミング言語一般の概念や、様々なプログラミング言語の意味についてのおおまかな説明といった感じだ。これからちょっとずつ読んで行こう。

_ [学校][その他]健康診断

先週、健康診断に行くのを忘れていたので、今日行くことに。血圧が結構高かったので、ちょっと心配だ。これからは、食生活にもっと気を使った方がいいかもしれない。

_ [Onion]演算子オーバーローディング

Onionでは演算子オーバーローディングを実装するつもりだが、今までどういう仕様については、あまり詳しく検討してこなかったので、ここらでちょっと考えをまとめてみる。

まず思いつくのは、一定の命名規約を決めて、それに従ったメソッド定義を、演算子の定義とみなすという方法だ。例えば、java.math.BigIntegerには、add,subtract,multiply,divideというメソッドがあるが、これはそれぞれ、+,-,*,/演算子のオーバーローディングとみなすことができる。例えば、

m :BigInteger = BigInteger::valueOf(100);
n :BigInteger = BigInteger::valueOf(200);
System::out.println(m * m + n * n);

を、

m : BigInteger = BigInteger::valueOf(100);
n : BigInteger = BigInteger::valueOf(200);
System::out.println(
  (m.multiply(m)).add(n.multiply(n)));

のように変換することができる。このように演算子をメソッド呼び出しに１対１に対応付ける方法でも、それなりには使えるが、問題点がいくつかある。

まず一番問題なのは、このように名前を決め打ちにしてしまうと、既存のライブラリの一部しか演算子オーバーローディングの恩恵を受けられないということだ。例えば、+をaddメソッドの呼び出しだと決めてしまうと、行列演算ライブラリがあったとして、加算メソッドがplusだったりすると、+演算子を使用することはできなくなってしまう。

ある演算子に対応付けられるメソッド名を増やそうにも、演算子からメソッド呼び出しに１対多の対応を付けることはできない。どのメソッドに対応づければ良いのかが、演算子だけからでは判断できないからだ。

また、もう１つの問題としては、元のクラスライブラリが想定していないデータ型同士の演算は定義できないことだ。例えば、BigIntegerとintの足し算を演算子+で行おうとしても、BigIntegerのaddメソッドの引数は、BigInteger型なので、int型との演算を行うことはできない。

これらの問題を解決するには、演算子の種類と適用されるデータ型に対して、メソッド呼び出しをマッピングする仕組みが必要だと思う。シンタックスとしては、こんな感じだろうか。

//BigInteger同士の加算は、addメソッドを呼び出す
operator m:BigInteger + n:BigInteger = m.add(n);


/*
 * BigIntegerとintの加算は、nをBigIntegerに変換してから、
 * addメソッドを呼び出す
 */
operator m:BigInteger + n:int = m.add(BigInteger::valueOf(n));


//Matrix同士の加算は、plusメソッドの呼び出し
operator m:Matrix + n:Matrix = m.plus(n);

このような仕組みを作れば、既存のクラスライブラリのメソッドに対して、自由に演算子を割り当てることが可能になる。

_ [ジョギング]5km

久しぶりに走ったせいか、かなり疲れた。