何か最近またよくウィルスメールがよく届くようになりました。 spamフィルタでは十分に取り除けないので、 かなりうざいです。 ClamAVの導入を真剣に考えるべきか。
コンパクトフラッシュでext2を使っていて、 パーティションの大きさを変更すると、 ちゃんと読めたり読めなかったりするという報告がありました。 どうもこれはおかしなバグっぽくて、 真剣にデバッグする価値がありそうなので、 少し見てみようと思います。
Multiboot Specificationの次期バージョンについて語れることは多いのだけれど、 一向に形にならないのが問題です。 みんな、アイデアは述べても仕様書書くところまでやってくれないしね。 やはり、ここは一つ、叩き台を書き上げてやらないといけないかな。
でもどうするのがいいか、私自身ちゃんと分かってないですからね。 既存の構造のまま、アーキテクチャ別の項目を作り、 アーキテクチャ毎の切り分けをしっかりやるという案も捨て難いし、 この際にもっと柔軟でパースしやすい形式に変更するという案も捨て難い。
GRUBの立場から言うと、 もっと扱いやすい形式になっている方が実装するのが楽。
ではOSの立場から見れば？ 新規のOS開発あれば、どっちでも似たり寄ったりか、 やりやすい形式になってくれた方がいいけど、 既存のOSはあんまり変更して欲しくないだろうなあ。 やっぱりよく分からんという結論になってしまう。
前から思っている不思議なこと。 なぜSchemeの実装はこんなにたくさんあって、 しかもまだまだ作られるのでしょうか。
似たような例はいろいろあって、 やたらと実装の多いカテゴリとして最も有名なのはエディタでしょう。 事実、 freshmeat.netのText Editorのカテゴリ には現在250のプロジェクトが登録されています。 freshmeat.netに登録されているプロジェクトなんて一部でしかありませんから、 きっとある程度使えるレベルのものは世界に1000以上あるに違いありません。
言語の話に絞ると、 言語の仕様が実装の外に存在する言語では、 複数の実装が開発されるのはある程度宿命なんでしょう。 例えば、Cコンパイラとか。 しかし、プロプライエタリだから作らざるを得ないという状況を除いて、 Cコンパイラでもそんなに存在するわけじゃありません。 実際フリーなものではGCCが事実上唯一の標準で、 他のものはあるのかないのかもよく分からない程度です。
同じLisp系であっても、 他のLisp系の実装はそんなにたくさんありません。 フリーなものに絞ってしまうと、 Common Lispだと今でも使われているのはGCL、CMU CL、Steel Bank CLぐらい？ いや、これでも意外と多いかも。 でもSchemeの比ではありません。
私が知っているだけでも、 Guile、MIT Scheme、Gauche、SCM、STk、VSCM、PLT Scheme、TUT Scheme、Elk、Biglooなどなど。 schemers.orgのリスト には嫌になるぐらいいっぱい載ってます。 大体GNUになっているものだけでもGuileとMIT Schemeの二つがあるなんて、 私のような門外漢には不思議を通り越して不気味なほどです。
Schemeは思わず自分で処理系を作ってみたくなる言語だそうですが、 それにしてもあんまりな気がします。 この乱立ぶりは初心者を恐がらせるには十分じゃよ。
ごもっとも。実装者の立場から見ると、Schemeの仕様というのは単に小さいから実装しやすいってだけじゃなくて、「実装上の選択が幅広く、また選択によって得手不得手がはっきり出るので目的に応じた選択をしたくなる」という特徴があると思います。例えばcall/ccの実装戦略は、C言語との親和性を重視するか、call/cc no
…call/ccの軽さを重視するか、によって実装の根本的なところが変わってしまいます。一方を重視した実装は、もう一方が欲しい人にとっては使い物にならないのです。コンパイラ重視でがりがり最適化をかけるか、インタプリタで動的にいじれることを重視するか、もそうです。他にも関数コールのABIだとかマクロだとか。文字列の内部表現も決まっていないので、マルチバイトでcopy-on-writeな実体を持つ、という戦略も許されます。言語仕様から実装戦略がだいたい見える言語と違って、想像力の余地が広いところが、実装者魂を刺激するんじゃないでしょうか。
昔多少Guileに関わっていたので、R4RSとかR5RSは結構読んだんですけど、そんなにたくさんのバリエーションがありますかねえ。基本的な方針はせいぜい3つか4つぐらいの実装でほぼカバー出来てしまう気がします。