On Thu, 17 Feb 2005 17:30:11 +0900, IMAI Takeo <usitukai / osk.3web.ne.jp>  
wrote:
>> まあ、有利不利以外にも環境とかツールの使いやすさとか各人の好み  
>> (Stroustrup
>> の場合、トップダウンに読んでいく方が好み)とかが関わってくる部分もあるの 
>> で、一概に何が正しいとは言えませんが。
>
>  「トップダウンに読んでいく」って、下向き構文解析の事ですか?

はい、そうです。

> 確かに
> StroupstrupはC++コンパイラをLL解析で作ったと聞いてますが。…というか、
> あの言語を上向きで解析するのは結構辛い、と思います。

ええと「C++ の設計と進化」によると、最初の C++ 実装である Cfront は、最
初薦められるままに YACC を使って書いていたけれど、最終的には YACC とは
相性の悪い再帰下降型のテクニックを大量に放り込んだハイブリッド型になっ
たようです。


>> >> ただし実験的な言語を作るのではなく仕様が既に定まっている言語を作る場 
>> 合は
>> 仕様が既に定まっている言語を作るのではなく実験的な言語を作る場合は」
>> > の間違い、、、でしょうか?
> (略)
>> いえ、最初の文章であってます。
>
>  へぇ…どういう意図があるんでしょうね。仕様が決まっていて、BNFの規模も
> それなりにある言語なら、パーザジェネレータ使った方が楽そうな場合が
> 多そうですけど。

ちょっと検索して調べてみたところ、「YACC  は少しずつ言語の機能を追加しつつ
作っていく場合には楽だけど、仕様が決まっている場合にはそうでもない」とか
「あまり変わらない」といった意見もあるようですね。

それが手続き型の言語にありがちなことなのか、それとも言語の形態を問わずよ
くあることなのか、それは分かりませんが。


あと、Haskell の方面ではパーサジェネレータならぬ parser combinator という
ものがあります。Parsec は実はこれにあたるのですが難しいという評判があるた
め、 yacc/lex に相当するツールを求めているのならば薦めるべきではないかな
と思って特に持ち上げませんでした。

parser combinator 自体が難しいわけではないんですけどね。実際 C++ で EBNF
もどきが直接かける Boost の Spirit はこれを元にしたものですし。


>  ちなみに、私が「yacc/lex」と書いたのは、特に解析アルゴリズムを指定して
> るわけではありませんでした。ANTLRやJavaCCみたいなのもありますし。
> HappyはLRみたいですが。

ちょっとジェネレータじゃないからグレーゾーンかな、って思ってしまって……。


-- 
shelarcy <shelarcy capella.freemail.ne.jp>
http://page.freett.com/shelarcy/