Ruby で記述してある LALR(1) 構文解析ツールといえば Racc だ、 と相場は決まっていて、私も便利に利用しています。ただし、Racc は実用性優先で、あまりに Bison を意識しすぎている上に、速度優先、内部のオブジェクトの構造がつくりこまれすぎときて、いじくって余計な機能をつけて遊んでみようとか、機能をちょっと変えてみようとかするには、まったくもって向いていません。 実用性よりも、内部をいじって遊ぶのに向いた小気味の良いピュア Ruby な LALR(1) 構文解析器もあって良いのではないかと考えて、作ってみました。構文解析表の生成部と駆動部をすべて組み込んで、500 行程度のコンパクトな解析器処理系です。構文記述はハッシュと配列に優先順位と生成規則のインスタンスを並べるだけで良いのですが、少しは記述性を上げてみようとの試みで、Ruby の組み込み演算子を使って生成規則を
SQLite 3.0.0 〜 3.5.4 の仮想データベース・エンジン(VDBE)はオペランドを3つ(P1、P2、P3)持つスタック・マシンの命令を実行します。VDBEのプログラムはテーブルに格納され、テーブルの行が一つの命令に対応しています。行には先頭から順番にゼロからアドレスがふってあります。これがジャンプ先のアドレスになります。 演算用のスタックとサブルーチンのリターン・アドレス・スタックに分かれています。スタックには整数以外に文字列やblob、テーブルやインデックスのレコード・エントリなどのいろんな型のデータをプッシュしたりポップできます。一般にスタックを使った2項演算は FORTH や PostScript と同様にトップと2番目をポップして、「2番目 (演算子) トップ」の結果をプッシュします。 スタック以外に、ステートメントにbindされた変数を取り出すVariable命令、
SQLite3 の SQL 文のオプティマイザがどのようにループの最適化をおこなったのかをてっとり早く調べるには、SQL コンパイラが生成した仮想データベース・エンジン(VDBE)のアセンブラのソースをEXPLAIN 文を使って眺めるのが早道です。なのですが……、EXPLAIN 文の出力のままでは、オペランドの種類がわかりにくい上に、ジャンプ先がどこにあるのか一目では見当がつきません。 そこで、EXPLAIN 文の出力を整形して可読性を上げる Perl モジュールを書いてみました。ただし、VDBE は SQLite のバージョンが上がるにつれて変化しており、全部に対応するのはめんどくさいので SQLite3 の 3.0.0 から 3.5.4 に限定しました。ちなみに、私が日常的に使用している環境では、Ubuntu Linux 8.04LTS に付属のバージョンが 3.4.2 で、MacOS
Ruby の添付ライブラリ test/unit は、Java のテスト・フレームワークを範にしているようで、煩雑で軽やかさがないのが難点です。なぜ、Perl のテスト・フレームワークに倣わなかったのか、Ruby の不思議の一つだと思っています。id:dankogai さんが不満を述べるのも、わかる気がします。 ⇒ 404 Blog Not Found:Ruby beyond Rails - 書評 - まるごとRuby! RubyはPerlに比べて、余計なところでTMTOWTDIを発揮しているように思えてならない。それを一番強く感じるのがテストのフレームワークで、なんであんなに種類があるのかわからない。TAPでほぼ統一されているPerlの連帯感からすると、テスト一個のためにクラスを書かせるなんて、間違った傲慢(false form of hubris)にしか感じられないのだが。 もっとも、賢
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く