ヘルプのおまけ

マニアックなカスタマイズを行うためのヒント。

• GtkAction
  • グローバルなGtkAction
  • 現在のセレクションへのGtkAction
  • 現在のViewへのGtkAction
  • 特定のコンテキストへのGtkAction
• Schemeインタプリタ
  • おちゅ〜しゃとScheme
  • おちゅ〜しゃ特有の手続き
  • Schemeによるカスタマイズ
  • おちゅ〜しゃのSchemeシステムの仕様
  • おちゅ〜しゃのSchemeシステムの特徴
  • おちゅ〜しゃのSchemeシステムの制限

---

おちゅ〜しゃの定義するGtkAction

おちゅ〜しゃはGTK+-2.4で導入されたアクションベースのメニューやツールバーという概念を用いて実装されています。

そのためメニューやツールバーに現れる要素には、対応するGtkActionが定義されており、グローバルキーバインディングの設定やメニュー・ツールバーのカスタマイズに用いることができます。

GtkActionは本質的にグローバルなオブジェクトであり、メニューバー、ツールバーおよびポップアップメニューの好きな所に、好きなように配置できるものです。

おちゅ〜しゃの定義するGtkActionはその操作の対象の性質で分類すると以下に記すように、グローバルなもの、現在のセレクションを対象とするもの、現在キーボードフォーカスを持つ表示部分を対象とするものおよび特定のコンテキストを対象とするものと、大凡四通りに分類できます。

以降の説明では次のような表記を用います。

「識別子」はochusha-ui.xml内のaction属性の値として用いる識別子です。

「accel-path」はochusha-accel-map.rc内のaccel_path指定に用いる識別子です。

「ニーモニック」はメニューなどに表れる、このGtkActionの表記です。

「キーバインディング」はデフォルトのキーバインディングです。

「GtkActionの説明」はこのGtkActionの説明です。

「補足」は実装上の制限などに関する補足説明です。

グローバルなGtkAction

厳密にはおちゅ〜しゃ本体のウィンドウに関連付けられたGtkActionであり、グローバルという言葉ではやや語弊がありますが、基本的にウィンドウを一つしか開けない現状のおちゅ〜しゃでは「書き込みウィンドウ」などの一部の例外を除き、いつでも有効なGtkActionです。

次のようなものがあり、主にメニューバーやおちゅ〜しゃの設定ダイアログに現れる要素に対応しています。

本質的にグローバルなGtkAction

操作対象というモノを必要としないか、あるいは対象が常に存在するような操作に対応するGtkActionとしては次のようなものが定義されています。

現在表示されているスレ一覧を操作対象とするGtkAction

操作対象が「現在表示されているスレ一覧」と固定されているGtkActionとしては次のようなものが定義されています。

スレ一覧が表示されていない場合、これらのGtkActionはinsensitive（無反応状態）になります。

現在表示されているスレを操作対象とするGtkAction

操作対象が「現在表示されているスレ」と固定されているGtkActionとしては次のようなものが定義されています。

スレが表示されていない場合、これらのGtkActionはinsensitive（無反応状態）になります。

おちゅ〜しゃの設定関連のGtkAction

おちゅ〜しゃでは、設定ダイアログだけでなくメニューバーやクリッカブルアイコンでも同じ設定を変更することができます。そのため、大多数の設定関連要素はGtkActionとして実装されています。

以下にあげるものが設定関連のGtkActionです。

現在のセレクションへのGtkAction

主にコンテキスト（ポップアップ）メニューとして用いられるGtkActionとしては以下のようなものが定義されています。

リンク専用のGtkAction

以下にあげるものは、スレなどに表示されるリンクや、板一覧の板、ブックマークのフォルダ以外の要素、スレ一覧のスレなど、おちゅ〜しゃ的にリンク扱いできるものをクリックしたり選択した結果セレクションにURLが存在する場合にのみ有効となるGtkActionです。

板一覧やブックマーク専用のGtkAction

以下にあげるものは板一覧やブックマークで要素が選択されている時にのみ有効となるGtkActionです。

ブックマークフォルダ専用のGtkAction

以下にあげるものはブックマークフォルダが選択されている場合にのみ有効となるGtkActionです。

スレ一覧専用のGtkAction

以下にあげるものはスレ一覧でスレが選択されている場合にのみ有効となるGtkActionです。

スレ内の特殊リンクを対象とするGtkAction

おちゅ〜しゃのスレ表示には見た目はリンクっぽいが、役割が特殊なものが現れます。以下にあげるものは、そういった特殊なリンクをクリックした時にのみ有効となるGtkActionです。

現在のViewへのGtkAction

ここで言う現在のViewとは、「サイドバー」、「スレ一覧タブ」、「スレタブ」のいずれかの内、現在キーボードフォーカスを持っているか最後に持っていたものを示します。

時々おちゅ〜しゃがキーボードフォーカスの在処に追従できない場合があり、それはバグですが、サイドバーにキーボードフォーカスがある場合を除外すると、タイトルバーにスレタイが表示されている時は「スレタブ」、スレタイが表示されておらず板名が表示されている時は「スレ一覧タブ」が現在のViewになります。

特定のコンテキストを対象とするGtkAction

以下は、スレ一覧もしくはスレのタブブックマーク部分のコンテキストメニュー専用のGtkActionです。

---

おちゅ〜しゃのSchemeインタプリタについて

おちゅ〜しゃは自前のSchemeシステムを用いています(ソースツリーのlibtscore以下にまとまっています)。バージョン0.5.x以前にはTinySchemeをベースとして改造したSchemeインタプリタを用いていましたが、おちゅ〜しゃをC++で新規設計・実装するにあたり、主に速度とメンテナンス性を求めて自前実装に切り替えました。

サードパーティ製のものを用いることに抵抗感があるわけではないのですが、TinyScheme並にコンパクトでおちゅ〜しゃに組み込みやすく、かつ、性能が良いものを見つけるのは困難でした（Boehm GCなどを使っているものは、何時何が起こるのか予測しづらいので選択肢から除外しています）。

――Schemeの実装そのものとして配布されているものは、やはり単体でのプログラミング言語システムとしての完成度、添付ライブラリの充実などを主要な目標として発展しているので、良いもの程大きくなるのは当然です。また、どちらかというとプログラムの全部もしくは大部分をSchemeで書きたいというユーザ向けに設計されているので、余所の言語で書かれたプログラムに組み込んでちょろっとScheme手続きを呼び出す……などという使い方にはシステムが大げさすぎます。

ネタ的に一度は一から書いてみたかったという理由もあります。

おちゅ〜しゃでのSchemeの使い方

おちゅ〜しゃでは、設定ダイアログっぽいもので選択可能にするなどという方針では選択そのものが煩雑になってしまうか、選択肢そのものが極端に多様化しうるような、そもそもアプリ本体にハードコーディングしてしまうのがイクナイ感じが否めない様々なモノを提供しつつ、かつ、（ユーザなど）サードパーティによるカスタマイズの余地を残したい――という場面でSchemeによる実装を用いています。

具体的には、現時点で以下の目的でSchemeによる実装を用いています。

• スレ一覧の着色方針の決定
• スレ一覧において、あるスレがユーザの興味を惹いているスレかどうかの判断
• スレ一覧のソーティング・フィルタリング
• スレ内リンクなどのコンテキストメニューのカスタマイズ
• ２ちゃんねるのDATファイルを表示する際に、URLっぽい文字列をリンクっぽく表現するための文書加工
• URLが画像へのリンクっぽいかどうかの判定
• 画像へのアクセス時にあると良いかもしれないURLの加工
• 画像の代わりに送られてきたHTML文書から画像URLを抜き出し、リダイレクトさせる

おちゅ〜しゃ特有の手続き

Scheme手続きによるおちゅ〜しゃのカスタマイズに利用可能なおちゅ〜しゃ特有のScheme手続きには、以下のようなものがあります。

ここに記載されていないものについては、今後仕様変更が予想されているか、現時点では全く使い道がないかのいずれかです。

現時点の実装では、実行時に板オブジェクトとスレオブジェクトの区別を厳密には確認してはいないため、これらを混同して適切でない手続きを呼び出すとおちゅ〜しゃがSegmentation Faultで落ちる可能性が高いことに注意。

(url-encode-string STRING)

STRINGをURLエンコードした文字列を返す。

(url-decode-string STRING)

URLエンコードされた文字列STRINGをデコードして得られた文字列を返す。

(board-get-bbs-type BOARD)

板オブジェクトBOARDの表す掲示板種別を示す整数値を返す。掲示板種別を表す数値は以下の変数に対応する。

OCHUSHA-BBS-TYPE-2CH

２ちゃんねる掲示板。

OCHUSHA-BBS-TYPE-MACHIBBS

まちBBS。

OCHUSHA-BBS-TYPE-JBBS-LIVEDOOR

ライブドアJBBS（旧したらばJBBS）。

OCHUSHA-BBS-TYPE-2CH-HEADLINE

２ちゃんねるヘッドライン。

OCHUSHA-BBS-TYPE-2CH-BE

（新設当時）文字エンコーディングがEUC-JPだった頃の２ちゃんねるBe掲示板。

OCHUSHA-BBS-TYPE-BBSPINK

BBSPink。

OCHUSHA-BBS-TYPE-BBSPINK-HEADLINE

BBSPinkヘッドライン。

OCHUSHA-BBS-TYPE-2CH-COMPATIBLE

２ちゃんねる互換の掲示板。

OCHUSHA-BBS-TYPE-2CH-COMPATIBLE-RO

２ちゃんねる互換の掲示板（読み込み専用）。

OCHUSHA-BBS-TYPE-2CHLIKE-EUCJP

文字エンコーディングがEUC-JPな２ちゃんねる風掲示板。

OCHUSHA-BBS-TYPE-UNKNOWN

OCHUSHA-BBS-TYPE-JBBS

OCHUSHA-BBS-TYPE-MITINOKU

OCHUSHA-BBS-TYPE-2CH-RESERVED

通常は現れない。

(board-get-url BOARD)

板オブジェクトBOARDの表す掲示板のURL文字列を返す。

(board-get-name BOARD)

板オブジェクトBOARDの表す掲示板名文字列を返す。

(thread-get-bbs-type THREAD)

スレオブジェクトTHREADの表すスレの掲示板種別を返す。値は(board-get-bbs-type BOARD)の返す値に準ずる。

通常は(board-get-bbs-type (thread-get-board THREAD))と同じ値が返るが、２ちゃんねるの「面白ねたニュース」板のように、鯖移転に伴い掲示板種別が変更になった場合には異なる値が得られる。

(thread-get-board THREAD)

スレオブジェクトTHREADの表すスレの属する掲示板を表す板オブジェクトを返す。

(thread-get-id THREAD)

スレオブジェクトTHREADの表すスレのID文字列を返す。

(thread-get-title THREAD)

スレオブジェクトTHREADの表すスレのスレタイ文字列を返す。

(thread-get-url THREAD)

スレオブジェクトTHREADの表すスレのURL文字列を返す。

(thread-get-rank THREAD)

スレオブジェクトTHREADの表すスレの属する板のスレ一覧内における最新の順位を返す。DAT落ちしたスレの場合には0が返る。

(thread-get-previous-rank THREAD)

スレオブジェクトTHREADの表すスレの属する板のスレ一覧内における前回の順位を返す。

(thread-get-number-of-responses-on-server THREAD)

スレオブジェクトTHREADの表すスレの鯖が保持していると期待されるレス数を返す。

(thread-get-number-of-responses-read THREAD)

スレオブジェクトTHREADの表すスレの既読レス数を返す。

(thread-get-number-of-new-responses THREAD)

スレオブジェクトTHREADの表すスレの前回のスレ一覧更新以降のレス数の増分を返す。

(thread-get-number-of-responses-available THREAD)

スレオブジェクトTHREADの表すスレのその時点で存在すると期待されるレス数を返す。

(thread-get-number-of-responses-to-read THREAD)

スレオブジェクトTHREADの表すスレの未読レス数を返す。

(thread-get-birthtime THREAD)

スレオブジェクトTHREADの表すスレのスレ立て日時を表すUTC時刻相当の整数値を返す。スレのID文字列を整数に変換したものと同値。

(thread-new? THREAD)

スレオブジェクトTHREADの表すスレがスレ一覧に表示されたことのないスレかどうかを返す。

(thread-alive? THREAD)

スレオブジェクトTHREADの表すスレが鯖に現存することが期待できるかどうかを返す。

(thread-stopped? THREAD)

スレオブジェクトTHREADの表すスレがスレストされていることが判明しているかどうかを返す。

(thread-marked? THREAD)

スレオブジェクトTHREADの表すスレに印がつけられているかどうかを返す。

(thread-hidden? THREAD)

スレオブジェクトTHREADの表すスレが隠されているかどうかを返す。

(register-threadlist-rule NAME LABEL DESCRIPTION PROCEDURE)

スレ一覧の表示規則を登録する。各引数の意味は以下の通り。

NAME

内部的に規則を識別するために用いられる文字列。同じ名前の規則が存在している場合、上書きされる。

LABEL

GUIのメニューなどに表示される文字列。

DESCRIPTION

規則の説明。GTK+-2.12以降の場合、規則選択のコンボボックスのツールチップとして表示される。

PROCEDURE

スレ一覧の表示時に、各スレについて一度ずつ実行される手続き。スレ一覧のスレはこの手続きの返す値の昇順でソートされ、#fが返されたスレはスレ一覧に表示されない。引数としてスレオブジェクトを一つだけ取る手続きでなければならない。

現時点でPROCEDUREの返す値はC/C++のlongとして取り扱われます。また、ソート済リストへの要素の追加に関して速度的に致命的な不具合を持っていたGTK+-2.4.x以前のGtkTreeSortableなGtkListStore対策のための実装上の都合を由来として、現時点では正の整数であることが期待されます――既におちゅ〜しゃはバージョン2.4.x以前のGTK+はサポートしないと決めているのでいつでも完全な整数を許す実装に変更することはできますが、int64_tもしくはdoubleを用いるように変更するという選択肢もあるので、検討中です。

(register-external-tool NAME LABEL DESCRIPTION TOOL-TYPE TEMPLATEorPROCEDURE)

リンクなどのコンテキストメニューに現れる外部ツールを登録する。各引数の意味は以下の通り。

NAME

内部的に規則を識別するために用いられる文字列。同じ名前のツールが登録されている場合、上書きされる。

LABEL

GUIのメニューなどに表示される文字列。

DESCRIPTION

ツールの説明。ファイル選択ダイアログのタイトルに用いられる。

TOOL-TYPE

ツールの種別を示し、どのメニューに現れるべきかを決めるシンボル。現在内部的には、'link-tool、'image-tool、'text-toolの３種類が予約されている。

TEMPLATEorPROCEDURE

メニュー選択の結果何をすべきかを定義するコマンドラインテンプレート文字列、もしくは、コンテキストを元にテンプレートを計算する手続き。おちゅ〜しゃはテンプレート文字列内の"%ARG%"というキーワードをコンテキストとして与えられたURLや画像ファイルのパス名、選択中の文字列などで置換し、その結果として得られた文字列をコマンドラインとして外部プログラムを実行する。テンプレート文字列内に"%FILENAME_FROM_ARG%"や"%FILENAME%"が現れた場合には、ファイル選択ダイアログを表示し、ダイアログでユーザが選択したファイル名で置換する。

Schemeによるカスタマイズ詳細

おちゅ〜しゃは特定の場面で予約してあるScheme手続きを呼び出し、その手続きに計算を任せることで、ユーザのカスタマイズ対象となりうるad-hocな計算をおちゅ〜しゃ本体にハードコーディングすることを避けています。

ここでは、それらの手続きのおちゅ〜しゃからの要求仕様を簡単に書いておきます。

同内容は/usr/share/ochusha/ochusha-init.scm.defaultあるいは/usr/share/doc/ochusha-0.6.0.1/ochusha-init.scm.default辺りにインストールされているだろうサンプルプログラム内にコメントとして記載されています。

(decorate-list-entry THREAD)

引数としてスレオブジェクトTHREADを取り、スレ一覧におけるそのスレの配色を決定するペア(前景色 . 背景色)を返す。

前景色や背景色の値には、おちゅ〜しゃの設定ダイアログでユーザが変更可能な前景色・背景色それぞれ４通りの色を参照する定数扱いの変数や、(gdk-color-parse 色指定文字列)で得られる値を用いる。

(interest-thread? THREAD)

引数としてスレオブジェクトTHREADを取り、ユーザが興味を持っているスレかどうかを判定する。

スレ一覧のpやnによるカーソル移動やスペースキーでのスレ読み込みの対象となるべきスレかどうかを判定するために用いられる。

(rewrite-message MESSAGE)

MESSAGEとして与えられた文字列をレスの内容として、表示用に加工する。

(image-link? URL)

文字列URLが画像へのリンクっぽいかどうかを判定する。

(rewrite-image-link URL)

画像へのリンクっぽいと判定された文字列URLについて、実際にアクセスするURLを決定する。

手続きの値としてはURLそのものを表す文字列もしくは(URL文字列 . Referer文字列)というペアが期待される。それ以外の値が返された場合、おちゅ〜しゃはURLそのものを画像へのURLとして取り扱う。

(redirect-image-link URL PAGE-SOURCE)

文字列URLが画像へのリンクっぽいとしてアクセスした結果、文字列PAGE-SOURCEというHTMLソースがHTTPのステータスコード200で返された場合に呼び出される。この手続きがURL文字列を返した場合、おちゅ〜しゃは返されたURL文字列を画像へのURLとして画像のダウンロードを再度試みる。この時、引数URLがHTTPリクエストヘッダのRefererとして用いられる。

おちゅ〜しゃのSchemeシステムの仕様

Revised⁵ Report on the Algorithmic Language Scheme（R⁵RS）準拠を目指して実装されていますが、まだかなーり中途半端なので難しいことはできません。

Revised⁶ Report on the Algorithmic Language Scheme（R⁶RS）は、おちゅ〜しゃへの組み込み専用の仕様としては規模が大きすぎるし、文字をUnicode表現にしなければならないのが面倒すぎるのでR⁶RS準拠を目指すことは当面考えません。仕様という観点での目標はR⁵RS仕様への準拠になります。

R⁵RS仕様だけでは不便なので、作者が必要と思った時に必要と思った機能が順次追加されていますが、その場合の追加仕様はScheme Requests for Implementation（SRFI）に適当なものがあればその仕様を、無ければ良く知られたライブラリやGaucheのように手軽に使えて、実績のあるSchemeシステムが提供しているものの仕様を頂いてくるという方針で決定しています。いずれはR⁶RSから一部の仕様を頂いてくるということもあるかもしれません。

現時点で実装されているScheme仕様

R⁵RSの大部分（？）

大部分が実装されていますが、例えばNumbersがまともには実装されていない（全ての数値表現がfixnumあるいはflonumでしかない）ように、Schemeシステム単体としてはかなり中途半端です。実装上の制限に関する詳細については後述します。

Basic String Ports (SRFI-6)

全部実装されているはずです。

Time Data Types and Procedures (SRFI-19)

date-week-number、date->string、string->date以外は実装されています。なぜこれらが実装されていないのかは忘れてしまいましたが、多分面倒だったからです。恐らく、使いそうだ……と思って実装を始めた挙げ句、やっぱイラネ……と思って放置されている悪寒。

Basic Format Strings (SRFI-28)

単純すぎるので、Intermediate Format Strings (SRFI-48)辺りを用意すべきかもしれません。

正規表現

正規表現はpregexp風のprocedureが実装され、プログラム内にはGauche風のリテラル表記（#/正規表現/もしくは#/正規表現/i（case insensitive）という表記）ができます。pregexpそのものではなく、実装に鬼車を用いているため、pregexp本来の正規表現とは異なる部分があるかもしれません。また、鬼車も全機能を使っているわけではありません。

おちゅ〜しゃのSchemeシステムにおける正規表現関連の手続きには以下のものがあります。

(string->regexp REGEXP)

文字列REGEXPに相当する正規表現オブジェクトを返す。#/REGEXP/との違いは、リテラル表記の場合にはSchemeコードのコンパイル時に一度だけ正規表現オブジェクトが作られるのに対し、手続きの場合には実行される度に作られるという点だけ（？）です。

もちろん引数のREGEXPは文字列に評価される任意の式が書けるので、リテラル表現としては書けない正規表現が必要な場合にはこの手続きが必要になります。

――リテラルでしかcase insensitiveが指定できないという違いもあるなー。

これはGaucheの仕様を真似した手続きです。Gaucheではキーワード引数というものによりcase insensitiveを指定できますが、現在のところはサポートしていません。

(regexp-match-positions REGEXP STRING)

正規表現オブジェクトREGEXPを文字列STRINGにマッチさせた結果の各捕獲集合について、STRINGに対応する部分文字列の(開始 . 終了)のようなペアのリストを返す。マッチしない場合は#fを返す。

(regexp-match REGEXP STRING)

正規表現オブジェクトREGEXPを文字列STRINGにマッチさせた結果の各捕獲集合について、STRINGに対応する部分文字列のリストを返す。マッチしない場合は#fを返す。

(regexp-split REGEXP STRING)

正規表現オブジェクトREGEXPを文字列STRINGにマッチする部分文字列をデリミタとして文字列STRINGを区切り、区切られた各部分文字列のリストを返す。

(regexp-replace REGEXP STRING REPLACEMENT)

正規表現オブジェクトREGEXPにマッチする文字列STRING中の最初の部分文字列を置換文字列REPLACEMENTで置き換えた文字列を返す。マッチしない場合は元の文字列そのものを返す。

(regexp-replace* REGEXP STRING REPLACEMENT)

正規表現オブジェクトREGEXPにマッチする文字列STRING中の全ての部分文字列を置換文字列REPLACEMENTで置き換えた文字列を返す。マッチしない場合は元の文字列そのものを返す。

(regexp-quote STRING)

文字列STRINGに正確にマッチする正規表現を返す。すなわち、文字列中に正規表現のメタ文字が含まれている場合にそれを'\'でエスケープした文字列を返す。

これらはpregexpの仕様を真似した手続きですが、以下の点においてpregexpとは違います。

• おちゅ〜しゃのSchemeシステムが対象とする文字列はUTF-8エンコーディングの文字列です。
• おちゅ〜しゃのSchemeシステムの提供する上記の手続きにおいて、正規表現のパターン指定は正規表現オブジェクトでなければなりません。pregexpのU-regexpはサポートしていません。正規表現オブジェクトについては、Gauche風のリテラル表記をサポートしているので、これは致命的な制限にはならないはずです。
• regexp-split手続きに、空のパターンを指定して文字列を分割した時の振る舞いがpregexpのものとは異なります。pregexpでは文字列STRINGをSchemeの文字単位に分割したリストを返しますが、おちゅ〜しゃのregexp-splitの場合には、文字列STRINGをUTF-8エンコーディングの境界で区切ったリストを返します。

おちゅ〜しゃのSchemeシステムの特徴

元々TinySchemeの改造で得た経験を元に設計・実装されていますが、ネタ的な目的もあって一から書いたのでそれなりに特徴があります。

覚えている分を列挙すると以下のようなものが挙げられます。

• TinySchemeと同じく、実行コンテキストがオブジェクトとしてまとまっているため、独立したSchemeインタプリタを複数同時に用意して用いることができる。
• Generational GCを採用したメモリシステムを用いています。発生するGCの大半を占めるMinor GCではCopying GCが実行されるので、停止時間が極端に短くなっています。おちゅ〜しゃの使い方では、Mark & Sweep GCだけを採用しているTinySchemeと比べて数十倍から数百倍というオーダで高速になっています。ちなみに、おちゅ〜しゃにおけるSchemeの使い方ではMinor GCしか起こらないと言っても差し支えありません。
• バイトコードインタプリタなのでコンパイラを頑張って書けばSchemeプログラムの実行が速くなるはずですが、今は微妙です。TinyScheme比で数倍〜数十倍程度には高速化できるはずですが、Gaucheなどに比べると数十倍というオーダで遅いので、コンパイラによる最適化の余地が相当残されていると予想しています。
• 小さな整数や文字はヒープに割り付けるのではなく、値をそのままオブジェクトとして用いています。

おちゅ〜しゃのSchemeシステムの実装上の制限

必要になってから実装するという方針で触っているので、現時点では以下のような制限があります。簡単に言えば、面倒だから書いてない部分がそれなりに存在します。

R⁵RS仕様の内、手抜き実装のもの

Numbers

面倒なので実装していません。おちゅ〜しゃ的にはfixnum程度の整数が扱えれば十分だと思っているので、fixnumな整数とflonumな実数だけを実装してお茶を濁してあります。fixnumはC/C++のlongの整数で、flonumはdoubleの浮動小数点数です。

library syntax: (cond <clause1> <clause2> ...)

library syntax: (case <key> <clause1> <clause2> ...)

library syntax: (do ((<variable1> <init1> <step1>) ...) (<test> <expression> ...) <command> ...)

library syntax: (let <bindings> <body>)

以上は面倒なのでR⁵RSに記載されているdefine-syntaxによる定義をそのまま使っています。現状ではコンパイラが賢くないので手書きによる処理でコンパイルされる他の類似syntaxに比べると出来上がるバイトコードがかなり低質で実行コストが多少高く付きます。……とはいえ、syntax以外までを考慮に入れると、これらのコンパイル処理を手書きするよりはコンパイラを賢くする方が恐らく最終的なコードの質が良くなるので、当面はこのままの予定です。

procedure: (eval expression environment-specifier)

難しい（？）のでproperly tail-recursiveな実装ではありません。evalを呼び出した側のコンテキストとevalにより評価される式のコンテキストとの間でcall-with-current-continuationなどにより捕獲されたcontinuationを何らかの方法で受け渡し、参照することは禁則事項です――エラーチェックなどしていないので不幸なことが起こるでしょう。

optional procedure: (load filename)

難しいのでproperly tail-recursiveな実装ではありません。loadを呼び出した側のコンテキストとloadにより読み込まれたSchemeプログラムのコンテキストとの間でcall-with-current-continuationなどにより捕獲されたcontinuationを何らかの方法で受け渡し、参照することは禁則事項です――エラーチェックなどしていないので不幸なことが起こるでしょう。

R⁵RS仕様の内、実装されていないもの

以下に列挙します。ここで挙げられていないのに実装されていない……というものは、現時点で作者が抜けていることすら忘れています。

以下には並べていませんが、Numbersの実装をサボっているので有理数や虚数関連の手続きは実装されていません。

syntax: (let-syntax <bindings> <body>)

面倒なので実装していません。これの実装よりも前にコンパイラを書き直すと思います。

library procedure: (map proc list1 list2 ...)

library procedure: (for-each proc list1 list2 ...)

procedure: (values obj ...)

procedure: (call-with-values producer consumer)

procedure: (dynamic-wind before thunk after)

library procedure: (call-with-input-file string proc)

library procedure: (call-with-output-file string proc)

optional procedure: (with-input-from-file string thunk)

optional procedure: (with-output-to-file string thunk)

これらは面倒なので実装していませんが、その内実装します。mapやfor-eachあたりは、おちゅ〜しゃのソースツリーに含まれているTinyScheme由来のinit.scmからSchemeによる実装を抜き出してそのまま使ってしまうのでも良いような気がしています。

---

$Date: 2008/12/28 07:23:47 $