とうとうビデオ公開っ。でも、時間がかかるのでとても全部は見れない。 Language Updateの範囲でのお勧めはOCamlか。
参加できなかった部分のビデオはなんとか時間を取って見ることにしよう。
SunがJRubyのメイン開発者であるCharles NutterとThomas Eneboを正式に雇った、という話。
とうとう来たよ。そういう時代が。
彼らのブログ
立役者(らしい)Tim Brayのブログ
もう11月かよっ。テーマは「理系・文系」。でも、書きおわらなかった。 正確には書きすぎたので削らなくちゃ。
日経Linuxの方は「HTTP+CGI」。こちらは半分ほど書けた。
Dave Thomasから「yacc捨てたいって言ってたよね、こんなのどう?」と紹介されたもの。
大変面白そうだけど、背景となる理論が理解できてない。
Cを対象にするコンパイラ・コンパイラがあれば理論なんて分かってなくても使えるけど、 どうもHaskell, Java, Tcl対象のものしかないみたい。 「自分で作る」ってのは避けたいしなあ。
This work is licensed under a Creative Commons License.
Parsing Expression Grammarは背景となる理論はともかく、<br>使う側としては無限先読みが可能でLexer-lessな再帰下降<br>パーザととらえておけば、おおむね間違っていないのでは<br>ないかと思います。特にLexer lessというところがRubyの<br>構文解析をする上では重要ではないかと思います。
http://en.wikipedia.org/wiki/Parsing_Expression_Grammar<br>の感じでは、文法では(REG、CFG)で使われるバックトラックや文法外の衝突解消をなくする、替わりに、先読みを丁寧に書き下して、それらの仕事を負担する。そうすると、memorize の利きが良い 線形アルゴリズムが使える。 メモリを多用してスピードを上げるのは最近処理のスタイルに合致する。巧妙な先読み文法をスラスラ書ける PEG脳 を持った人々を養成する必要がある。
PEGではバックトラックあるはずですよ。>MMXさん<br><br>上のリンク先から引用:<br>> The choice operator e1 / e2 first invokes e1, <br>> and if e1 succeeds, returns its result immediately. <br>> Otherwise, if e1 fails, then the choice operator <br>> backtracks to the original input position at which <br>> it invoked e1, but then calls e2 instead, returning<br>> e2's result.<br><br>memoizeの利きが良い線形アルゴリズムというのは、<br>たぶんPackrat Parserのことかと思いますが、Packrat Parser<br>のアルゴリズムは、先読みとは無関係のはずです。
みずしまくんの話を某所で聞いて「いや〜技術って、ほんとに進歩してるんですね」と思ったんですが、Rubyを実装するための現実的な問題は「Cを対象にするコンパイラ・コンパイラ」がどこにあるか、ですね。<br>あくまで言語処理系実装者は、コンパイラコンパイラの利用者なわけで。このインターフェースのキャズムを埋めてくれる誰かがいないと…。