アカウント名:
パスワード:
昔は構文木をテーブルで持つyaccは富豪のツールと思ってましたが、最近ではそれ程贅沢な感じがしないのは堕落したせいかもしれない>オレ
昔は構文木をテーブルで持つyacc
昔話をすると爺くさくてやなんだけど、僕は昔kmyaccというクローンを実装しまして、CP/M(80の方)上で動かしてました。Cの構文程度ならちゃんと処理できましたよ。
yaccって、人が思ってるほどメモリ食うもんじゃないです。生成されるテーブルもかなり圧縮されてますし。
ただし、「それ程難しくない」とは言えないなあ。このifconfigの構文程度なら簡単でしょうけど。
実際、conflictが出まくると頭かかえちゃいます。
BNFわからなければRFCも読めませんから当然みんな判ってるはずですよね
しかしこのストーリーの閑散とした状況(コメント数19)を見ると、そうじゃないんでしょうね。/.Jって、"News for Nerds, Stuff that matter"なんてごたいそうなこと
knuth博士の博士論文って、LR文法じゃありませんでしたか?
大学の情報系学科でも形式言語理論をLRやらLALRまでやってる学科は日本国内では少ないように思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
kameで (スコア:0)
途方に暮れたことがあります。
gdbで追っていくと、confファイルを読んで
プログラム内のtmpリストに追加しているように読める。
そして、ちょうどメンバ数2までの制限が
かかってることまではわかったが、改造出来ない・・・。
そしてまわりを見回しても、C+スクリプト言語(sed,awk,per
yaccは便利 (スコア:0)
BNFさえ理解できれば、後はそれ程難しくないですね。お約束レベルの事をいくつか憶えればおしまい。
BNFわからなければRFCも読めませんから当然みんな判ってるはずですよね:-D
昔は構文木をテーブルで持つyaccは富豪のツールと思ってましたが、最近ではそれ程贅沢な感じがしないのは堕落したせいかもしれない>オレ
Re:yaccは便利 (スコア:3, 参考になる)
昔話をすると爺くさくてやなんだけど、僕は昔kmyaccというクローンを実装しまして、CP/M(80の方)上で動かしてました。Cの構文程度ならちゃんと処理できましたよ。
yaccって、人が思ってるほどメモリ食うもんじゃないです。生成されるテーブルもかなり圧縮されてますし。
ただし、「それ程難しくない」とは言えないなあ。このifconfigの構文程度なら簡単でしょうけど。
実際、conflictが出まくると頭かかえちゃいます。
Re:yaccは便利 (スコア:1)
昔ずいぶんお世話になりました。どうもありがとうございます。
ちょっとしたインタプリタ風ツールの入力解析やら#446560のACの方同様の設定ファイルの解析やら程度にしか使ってませんでしたが、私みたいに頭の出来のよろしくない奴が手で書くぐらいだったらyaccに吐かせたほうが効率のいいものができたような気がしてました。
(パーサの類を手書きすると状態遷移が多すぎてわけがわからなくなって、実行時間やメモリの話以前に結局いつになっても物が出来上がらないからだ、というオチは伏せておきます…)
ついでに言うと、そんな程度のものでもなかなかconflictの解決ができずに頭をかかえちゃったりして。「それ程難しくない」といえる人がうらやましい…
まあ、最初の投稿者の方の話じゃないですが、使っている人自体少ないし使いこなしている人はさらに少ないというのは当たっているかなと思います。
それはさておき、今手元で動いてるFreeBSD5.1のifconfigのマニュアルを見ると、「こんなの手で書きたくない!」とは思いますね。yaccを使おうというのは正しい選択かなと。
Re:yaccは便利 (スコア:1)
bisonやFreeBSDに付属のyaccに比べて、出力するコードがコンパクトだし、
liby.a が要らないのがUNIX/Win(BorlandC++)でコードを共用するのに便利なもので。
Re:yaccは便利 (スコア:2, 参考になる)
最近C++のboost::spirit [boost.org]という構文パーサにはまっております。
非常に良く出来た(変態的な)ライブラリで、yaccや組み込みSQLのような別の処理系や
プリプロセッサを使わず、生のC++コードにEBNFもどきの文法とアクションを直接埋め込んで
構文・字句解析ができるようになっています。
yaccとは一味違うEBNFを採用していること、無理やり感のある独特な構文表記、
Javaに押されぎみでマイナー感が出てきたC++と、いろいろ絡み合って、正にアレゲな感じです。
複雑な構文を処理するならyacc/flex、そうでないならspiritと使い分けたいのですが、
もともと少ないC++プログラマで、さらにEBNFが理解できる人があまりいないのが玉に傷。
興味ある方は選択肢のひとつとして調べてみると良いことがあるかもないかも。
#yacc++とかはおいかけてないので、よく分かりません
Re:yaccは便利 (スコア:2, 参考になる)
#まだ途中みたいですが…
Re:yaccは便利 (スコア:0)
使ってみてもよさそうだけどGCCと組み合わせたときがどうなるか…
Re:yaccは便利 (スコア:2, 参考になる)
C++ + templateなんで、かなりCPUを消費します。
まだ小規模なとこにしか使っておりませんが、数十~百行程度
のEBNF構文定義であれば最近のPCでストレスなくコンパイル
できます、が、それ以上の規模になるとどうなるかわかりません。
#VC7.1+P4 3GHzなんで、gccを使う場合参考にならないかも
シンボルテーブルを食い尽くすらしく、デバッグ用のオプションを
少し弱めに変更しないとうまくリンクできませんでした。
他に気づいた点で言うと、yaccで生成したものと比べて実行時に
スタックを消費する傾向があるので、その辺も注意したほうがよいでしょう。
等価な文法を食わせて統計を取ってみると面白そうですね。
Re:yaccは便利 (スコア:0)
しかしこのストーリーの閑散とした状況(コメント数19)を見ると、そうじゃないんでしょうね。/.Jって、"News for Nerds, Stuff that matter"なんてごたいそうなこと
Re:yaccは便利 (スコア:1)
knuth博士の博士論文って、LR文法じゃありませんでしたか?
Re:yaccは便利 (スコア:1)
Perl::RecDescent [ibm.com]にせよ、JavaCC [ibm.com]にせよ。
JavaCC に関しては必要に応じて先読みトークンの数を増やせるという仕様があるので、
LALR を使うまでもないことのほうが多いのかもしれませんが。
Re:yaccは便利 (スコア:0)