gniibe


Gauche:Debian というページにすべきか?

ここから下は、2002に書いたこと。


Gauche を Dreamcast, Zaurus で使うところ。 DirectFB + GTK+FB + Gauche-GTK + Gauche という構成。

UTF-2000 も。

Anthy の言語として Gauche 使えないかなぁ。


だんだん思い出してきたシグナルの話(つづく。。。)

SCM では、拡張の C のコードを書くのが大変だぁ、と思った。

Guile では

1998 年ころ SCM のセマンティックスは、あんまりだろうと いうことで、Threads Support の提案の際に変えることとなった。 Guile 1.4 以降は、Guile のシグナルは、C のコードの任意の間で呼ばれることは、 なくなった。

一般の UNIX プログラミングにおけるシグナルの利用


マルチスレッドアプリケーションに使われるライブラリの性質


ついでに思い出した SCM/Guile の話

Shiro (2002/12/01 23:33:13 PST): full continuationはCの実行モデルとの相性が最悪なので、 Cから手軽に呼べる拡張言語と位置付けるなら無理にサポートする必要は ないと思います。SCMの方法 (Cスタックまるごとコピー、リカバー)は確かに 目から鱗でしたが、いかなる場合でも複数回returnがあることを考えて Cコードを書くのはきつすぎます。 そもそもエラーハンドラをSchemeで書くことを許した途端、 基本関数でさえCから安全に呼べなくなってしまいます。

また、SCMの方法はcontinuationの作成も呼び出しも高価であり、 他で書かれたfull continuationを使ったコードを動かしてみることが出来る、 以上のメリットは無いと思います。 あれだけ重いと自分で書く時に積極的に使う気にはなれません。

さらに、既存の外部ライブラリへのbindingを書いて、 外部ライブラリからSchemeへのコールバックを許す場合、 その外部ライブラリが複数回のreturnを考慮されて書かれている 可能性はほぼ皆無でしょうから、実用上、コールバック内で作られた continuationはコールバックから戻った後では安全に呼ぶことは 出来ないでしょう。

拡張言語として使う場合、SchemeフレームからCフレームへのreturnは たかだか一回に制限する、ということで妥協するしかないと思います。 continuationのエクステントを制限したくない場合は、 C側で意識してトランポリンを書いてやれば良いわけで。

2002/12/02 16:33:30 PST Hagedou. Completely agreed.

More ...