続 Ｃ言語でオブジェクト指向

バスに揺られた帰り道に思いついた。
忘れないうちにメモしておこう。

unionを使えばいいのかもしれない。
よくよく考えてみれば、設計の段階で回避できる問題なのだからこんな感じにしたらいけそうな気がする。
(対象はSchemeのポート周り)

struct Port
{
  int type;
  int direction;
  int (*close)(Port*);
  union {
    struct BinaryPort *bport;
    struct TextualPort *tport;
    struct CustomPort *cport;
  } impl;
};

typeでバイナリ、テキスト、またはカスタムポートか判別。directionでIN/OUTの判別。実際のポートの実装はimplで行って、closeとかすべてに共通しそうなのは上位に入れる。
(どうせ、そうは行ってもそれぞれのcloseを呼ぶことになりそうな気はするので、もう少し練る必要がありそうだ)

メタクラスも考えたが、一朝一夕ではいい案が出ないのと、Scheme内で使うところまで考えないとオーバースペック(苦労に見合わないとも言う)になりそうなのでとりあえず却下。
(Glib、Gaucheのソースを見たけど結構大変そうだったので。いろいろ魅力的ではあるが、自分の手に余りそうだし、recordを使えば一応クラスっぽいのも定義できるのでという理由)

明日この方向で実装を再開しよう。
ポート周りが終わらないと始まらない辛さ・・・

C言語でオブジェクト指向

ただいま絶賛挫折中・・・orz

その昔(といっても2ヶ月くらい前か？)途中で開発方針変えたため放棄したC++のソースをCに移植してる最中でぶつかった壁。
まだぶつかってるので躓いてる壁か？

単一クラス、振る舞いは変わるが継承、多態はないのなら、こんなのでいける。

typedef struct ObjectRec Object;
struct ObjectRec
{
  int x;
  int y;
  int (*squre)(Object*);
};

こんなことして、適当に関数ポインタに関数を突っ込んでやればいい。
たとえばこんなの。

static int realSqure(Object* o)
{
  return o->x * o->y;
}

static int fakeSqure(Object* o)
{
  return o->x * o->x * o->y * o->y;
}

Object* makeObject(int x, int y)
{
  Object* o = (Object*)malloc(sizeof(Object));
  o->squre = realSqure;
  o->x = x;
  o->y = y;
  return o;
}

Object* makeFakeObject(int x, int y)
{
  Object* o = (Object*)malloc(sizeof(Object));
  o->squre = fakeSqure;
  o->x = x;
  o->y = y;
  return o;
}

これで、同じo->squreなのに違う関数にアクセスできる。
この辺まではいいんだよ。昔から使ってたから。問題は継承が絡んでくると意味が分からん。
vtable使うか、メタクラスを別に作って気合でアクセスするか。
(多分、メタクラスを使った方が後々いい気がする。GObjectとかを参考にするか)

くそ、C++でかければこんなことで悩まないのに・・・
みんなDLLが悪いんだ！

クロワロタwwwww

性の６時間を正すために６時間正拳突きをしようと思う。某巨大掲示板に立ったスレをまとめたもの。

クソ笑った。あほすぎる。でも、これ日本にいてリアルタイムで発見したら大阪までスネークに行ってたかもｗ
いや、どちらかといえばリア充寄りだと思うけどね、僕。
これだけ行動力があるのなら、もう少し建設的なことに使えばいいのに、とも思ったが。
(別に彼女を作るとかじゃなくて、勉強でもいいと思うし、昨今の政治家に対してのデモとか)

でも、個人的には愛するべきあほだと思う。

そうそう、Merry Christmas!

C++/Cで書き始めたい

だいぶ自前Schemeがまとまってきたので、そろそろC++かCで書き始めようと思う。
コンパイラ(＋その周りのライブラリ)はコンパイルされたコードをC(多分CよりなC++)にコンバートすればいいとして、
(それでも、ライブラリのインポートとか識別子どうしようとか問題はあるけど)
どこまでをCで書いて、どこからをC++で書こうか迷い中。

迷う理由としてはこんな感じ。

1. C++だとバイナリ互換がない、つまりアプリケーション組み込みに向かない
2. C++にはtemplate、class、関数オーバーロードなどCにはない機能がある

1.はアプリケーション組み込みをするのかという話にもなる。でも、たとえばDLLでモジュール(ライブラリか？)を作成したいと思ったときに、CまたはC++で書くなら必要になる気がする。
(同じコンパイラ使えばいいんだけどね、実際)
2.は要らないといえば要らないが、あるとすっきりかける気がする。慣れの問題だとは思うが。

おそらく問題になりそうな部分としては、オブジェクトの扱いかなと。
結局こいつらをC++で書くと先に書いた、DLLでモジュール作成に支障が出る気がする。
Gaucheは完全にCだが、Ypsilonは一部Cで主にC++で書いてる。
見ればオブジェクトは単なるポインタで、それぞれのオブジェクト、Pairを除く、にヘッダ(単なるunsigned int)を持たせてる。
Moshは全部C++で、オブジェクトはクラスなんだけど、タグと値を保持するだけ。
(まぁ、その他便利関数が入ってるけど)

MoshとYpsilonを混ぜるのが答えになる気がする。
こんな感じで

typedef struct ObjectRec
{
  uint32_t tag;
  void*    value; //多分こいつはintptr_tとかにしないとまずい
} Object;

っで、シリアライズ可能なオブジェクトはCで書いて、PortとかシリアライズできそうにないのはC++で書けばいいかな。

そもそも、C++のABIがもっとポータルならいいのに。問題の一つは名前マングルにあると思うんだ、うん。
(try-catchの実装とかもそうか・・・)

続 R6RSのライブラリ その４

理由が全然違うことが発覚した・・・orz

原因はletrec-syntaxでsyntax-rulesにキーワードを入れたら正しく動作しないのが原因だった。
マクロ展開難しすぎる・・・
(ほぼ、Gaucheのを流用してるのになぜ？)

R6RSのライブラリ その４

ライブラリというよりはコンパイラ自身の問題か。

現在自前コンパイラを一つのライブラリにしてコンパイルしようとしている。
コンパイラはGauche上で実装されているので、Gaucheが実行できるコンパイラとそれをR6RSのライブラリにしたコンパイラと2種類ある。
(別に管理するのは面倒なので、cond-expand等を用いてできる限り最小限の重複にしてる、つもり)
っで、ライブラリのコンパイラは一つのライブラリなのにサイズが100KBを超える。多分この辺で問題が発生してる(と思う)。

libraryのコンパイルの順序として、
参照名の解決(不完全実装)、import句の解決、export句の解決、bodyのコンパイルという順番で行っているのだが、
bodyをコンパイルするさ際に、イメージとしてbodyをbeginで包んでからコンパイルしている。
こうすることで1つコンパイル、実行、というのを繰り返さず、全体をコンパイルして実行という感じにできる。
っで、(多分)上記のサイズが問題になってくる。
メモリが足りてないような症状が出てる気がする。というのも中間表現をライブラリ毎にダンプした際に、コンパイラのダンプだけ途中で途切れているからだ。
(本当に途中。ダンプせずに実行するとベクターじゃなく#fだって起こられるのに、ダンプするとぷっつりと死ぬ)
これがWindows版Gaucheだからなのか、そもそもベクターであんまり巨大(といっても目視で16MBしか使ってないけど)なデータを使えない仕様なのかわからない。

解決案は多分いくつかあって、簡単なのでライブラリの分割かな。
ただ、ライブラリを分割するということは、内部にとどめておきたい機能を外部公開する必要がでてくるので、すごく嫌だ。
一つのファイルに複数ライブラリを記述して、参照解決の際の検索方針とかでJava風なライブラリ解決にすれば、実質使えないかもしれないが、ものすごく抵抗がある。
(将来的に直すということにして現状の解決ためということにすればいいのかもしないけど・・・)

さて、どうしたものか。

R6RSのライブラリ その３

この話題ばかりだ・・・

展開のフェーズの話。(というよりは依存関係か)
たとえばこのコード

(library (my-lib)
    (export sub)
    (import (rnrs))
  (define (bigger? x)
    (or (> x test)))
  (define-syntax sub
    (lambda (x)
      (syntax-case x ()
 ((_ a b)
  (or (bigger? (syntax->datum #'a))
      (syntax (let ((x b))
         (- x 10))))))))
  (let ()
    (sub 10 x)))

このコード、一見何もないように見えるけど、走らせると死ぬ。
一見何もないように見えるという段階でR6RSのライブラリについて理解してないのだが・・・orz
問題は、subの中で使われているbigger?がフェーズ０でしか参照されないこと。
subが展開されるのはひとつ前のフェーズ1なので、単純にunbound variableな例外を投げてくる。
これを解決するには、bigger?を別ライブラリにして、expandで読み込む必要がある。

まさにこれにはまっていて、
自前実装のコンパイラにライブラリを実装して、R6RSのライブラリにコンバートしてコンパイルなんてことをやっているのだが、
依存関係の解決が面倒くさすぎる。
たとえば、こんなコード

(define something 10)
(define-macro (generate)
  `(make-vector ,(- something 5)))
(define generated (generate))

こんな感じのをライブラリにするとなると、somethingは外出しにしないと上記の理由で死ぬ。
というか、すでに死んでいる・・・
(逆に考えれば、意外と適当に実装したのに、その辺もうまいこと動いているということだが・・・)

これはライブラリの仕組みが悪いのか、Schemeにマクロがあるのが悪いのか(そもそも良い悪いの問題ではないと思うが)
わからないけど、あまり相性が良くない気がする。
プログラマがいろいろなことを気をつければいいのだけど、R5RSで書いてて、R6RSにコンバートするって時に(まさに今）非常に不便・・・

続 R6RSのライブラリ その２

よく考えたら(define id expr)の形式で定義されるidは自前VMだとライブラリをプロパティとして持つので、
そこを参照すればいいことに気づいた。
(もともとそのためのものなので早く気づけよ)

とりあえず、importのforキーワードについてはガン無視することにした。
あまりに理解して無さすぎなのと、明確にマクロ展開時((meta 2)以降はそれ以前になるの？)とコンパイル時と分かれているわけではないので、
実装しても煩雑になる上にあまりメリットが享受できそうになかったから。(単なる言い訳)

いい加減ながらライブラリの実装がほぼ完了。あとはバージョンを残すのみ。
でも、バージョンなんてどう管理すんだ？ということで少し整理。
現在のライブラリの構造。

top-libraries - 単なるハッシュテーブル
library       - name, imported, exported, tableを持つクラス(もしくは構造体)になる予定
                (現在は単なるベクター)

構造として
top-libraries = (lib1 => (lib1 instance)
                 lib2 => (lib2 instance))
こうなってるので、このどこかにバージョンをねじ込む必要がある。

案１：
もう一枚かませる。こんな感じ。
top-libraries = (lib1 => (version1 => (lib1 v1 instance)
                          version2 => (lib1 v2 instance))
                 lib2 => (version1 => ... ))

案２：
キーにしてる名前にバージョンをくっつける。
top-libraries = (lib1version1 => (lib1 v1 instance)
                 lib1version2 => (lib1 v2 instance))
                 lib2version1 => ... )

案３：
そんなことよりカラオケ行こうぜ！

３は無いとして(当然)、２だと微妙にメモリ消費が少なくなる気がするけど、バージョンマッチで死ぬ気がする。
１は現状の構造をいじる必要があるので、少し大掛かりになりそう(そうでもないが)

あぁ、そもそも、キーを(name version)みたいにして、やればいいのか。
(rnrs (6))みたいな例だと(rnrs (6))ってそのままになるな。
(com hoge fuga)ってのだと、適当にバージョン振る必要があるから、まぁ１だろう、こうなる？(com hoge fuga (1))
ということは、バージョンが無いものに関してはバージョンを振って、あるものはそのままキーにすればいいのか。
っで、参照する際に名前とバージョンを解決すればOKと。
とりあえず、この方法で行ってみよう。

どうでもいい話題で、export-allなんてのを作れないかなとか考えていたのだが、
結構大変そうだなぁということに気づいた・・・
importしたシンボルはまぁいいとして、中で定義されてるのを引っ張り出すのが大変そう・・・
でも、rnrsとかの巨大ライブラリを書くときに、export句に全部書き出すのって大変じゃね？っていうだけの話。

R6RSのライブラリ その２

前回の投稿にコメントをいただいて、ちょっと舞い上がっていたり。
(と同時に、Googleか何かの検索エンジンで調べた結果、役立たずなブログにぶつかったぞ、この野郎！と思われてないか不安にもなったり・・・)

自前実装で、簡単なimportとexportを実装したら不思議な現象(いや、原因はわかっているが)に出くわした。
R6RSのライブラリのフェーズの部分というかimport句の部分なの（か？)
前回syntax-caseで書いた部分、

(library (my-lib2)
         (export sub)
         (import (for (my-lib1) expand)
                 (rnrs))
　　(define-syntax sub
    (er-macro-transformer
     (lambda (form rename compare)
       (or (bigger? (cadr form))
    `(let ((x ,(caddr form)))
       (- x 10))))))）
(library (my-lib3)
         (export result)
         (import (my-lib2)
                 (rnrs))
  (define (result x)
    (sub 10 x)))
(import (my-lib3)
        (rnrs))
(display (result 10))

my-lib2は展開するためにbigger?をimportしてる。
っで、これが実際に呼ばれる部分はmy-lib3内なので、問題が起きる。
(er-macro-transformerをsyntax-caseの代わりに使ってるからかもしれんが・・・)

書いてる途中で、単に名前解決の仕方がおかしいだけということに気づいた。
考えをまとめるのに、何かに書くというのは有効であるｗ
my-lib3読み込み → マクロ展開※１ → ライブラリコンパイル
という流れで、※1の展開時にmy-lib2内でexportされてないけど必須になるbigger?の解決を行えばいいのだろう。
一時的にmy-lib3内に取り込んで、展開終了時に開放すればいいか？
まじめにフェーズを実装すればいいんだろうけど、大変そうだしなぁ・・・(よく理解してないし。。。)

R6RSのライブラリ

とりあえず、ここを読んでからR6RSを読んでみた。
まぁ、理解できたが、じゃあ既存の実装はどうなってるの？と思い調べてみた。

調査対象：Petite Chez Scheme、Ypsilon、mosh(nmosh)
調査プログラム

(library
    (my-lib1 (1))
    (export bigger?)
    (import (rnrs))
  (define (bigger? x)
    (or (> x 10))))
(library (my-lib2)
    (export sub)
    (import (for (my-lib1) (meta 1)) ; run expand (meta 0) (meta 1) (meta 2)に適宜変更
     (rnrs))
  (define-syntax sub
    (lambda (x)
      (syntax-case x ()
 ((_ a b)
  (or (bigger? (syntax->datum #'a))
      (syntax
       (let ((x b))
  (- 10 b)))))))))
(library (my-lib3)
    (export result)
    (import (my-lib2)
     (rnrs))
  (define (result x)
    (sub 10 x)))
(import (my-lib3)
 (rnrs))
(display (result 10))

こんなの。特に何の意味もないプログラムだが、フェーズを調べるには必要十分なのでOK。

で、結果。
run:
petite: 0
Ypsilon: 0
nmosh: error bigger?がない
expand:
petite: 0
Ypsilon: 0
nmosh: 0
(meta 0):
petite: 0
Ypsilon: 0
nmosh: error bigger?がない
(meta 1):
petite: 0
Ypsilon: 0
nmosh: ０
(meta 2):
petite: 0
Ypsilon: 0
nmosh: error bigger?がない

見た感じとして、Petite、Ypsilonはフェーズ関係をガン無視してるくさい。Shibuya.lisp #2か#3だかの資料によると、バグくさいのも実装したと言っているので、意図的？なものかもしれない。Petiteはよく知らん。
逆にnmoshはこの辺の宣言がきちんとされていないとまずいみたい。これはAndre Van Tonderのexpanderがそういう実装なのだろう。
この辺は仕様書に明確に書いてあるので、nmoshが正解なのだろうが、そんなもの考えてプログラム書きたくないなぁと思うとYpsilon実装にした方がいいのか？

昨日の風景

今日は3度と暖かいので、雪が融けてきてる。いいことだ。

ライデン中央系の様子。

どこが道だか分からんｗ

近所の川(というか溝というか運河というか)の様子。

どこが水だった場所でしょう？
正解は中央部分。木の柵に見えるのは橋なのでその周りの雪は水だった場所です。
今は融けてるはず。(今日は確認して無いので不明)

今週からは暖かいはずなので、ちょっと一息といったところか。

寒い！！

今週くらいから急に、しかもとてつもなく寒くなった。
現在午前7時、気温-6度!!
天気予報によると、風が強いので体感は-20度(!?)くらいらしい。

ようこそミニ氷河期へ。
地球温暖化とはいったいなんだったのか・・・