パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

FreeBSDでのifconfigリファクタリング作業」記事へのコメント

  • by Anonymous Coward on 2003年12月03日 1時26分 (#446493)
    kameをハックしてた時、yaccとかlexが全くわからなくて
    途方に暮れたことがあります。

    gdbで追っていくと、confファイルを読んで
    プログラム内のtmpリストに追加しているように読める。
    そして、ちょうどメンバ数2までの制限が
    かかってることまではわかったが、改造出来ない・・・。

    そしてまわりを見回しても、C+スクリプト言語(sed,awk,perl,...)
    が出来る人はいるが、yaccは0。
    マイナーなんですかね。
    構文解析に向いてて便利そうというのはわかったんですが。

    #yacc(ヤック)を"やっこ"だとずっと思ってたのでAC
    #やっこの方がかっこいいはず・・・。
    • Re:kameで (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2003年12月03日 15時59分 (#447002)

      yacc の難解さに嫌気がさした人々が、富豪的に XML を使ったりするんでしょうね。

      コメントの記法やら継続行の記法やら特殊文字のエスケープの方法やら、アプリケーション毎に違うのは勘弁…

      親コメント
    • by Anonymous Coward
      デカルチャ
    • by Anonymous Coward
      yaccは設定ファイルの構文解釈に便利なので良く使ってます。
      BNFさえ理解できれば、後はそれ程難しくないですね。お約束レベルの事をいくつか憶えればおしまい。
      BNFわからなければRFCも読めませんから当然みんな判っ
      • Re:yaccは便利 (スコア:3, 参考になる)

        by cloudy (1160) on 2003年12月03日 4時27分 (#446572)
        昔は構文木をテーブルで持つyacc

        昔話をすると爺くさくてやなんだけど、僕は昔kmyaccというクローンを実装しまして、CP/M(80の方)上で動かしてました。Cの構文程度ならちゃんと処理できましたよ。

        yaccって、人が思ってるほどメモリ食うもんじゃないです。生成されるテーブルもかなり圧縮されてますし。

        ただし、「それ程難しくない」とは言えないなあ。このifconfigの構文程度なら簡単でしょうけど。

        実際、conflictが出まくると頭かかえちゃいます。

        親コメント
        • by Rekishi (10137) on 2003年12月03日 6時06分 (#446603)
          もしかしてkmyaccの作者の方ですか?

          昔ずいぶんお世話になりました。どうもありがとうございます。

          ちょっとしたインタプリタ風ツールの入力解析やら#446560のACの方同様の設定ファイルの解析やら程度にしか使ってませんでしたが、私みたいに頭の出来のよろしくない奴が手で書くぐらいだったらyaccに吐かせたほうが効率のいいものができたような気がしてました。
          (パーサの類を手書きすると状態遷移が多すぎてわけがわからなくなって、実行時間やメモリの話以前に結局いつになっても物が出来上がらないからだ、というオチは伏せておきます…)

          ついでに言うと、そんな程度のものでもなかなかconflictの解決ができずに頭をかかえちゃったりして。「それ程難しくない」といえる人がうらやましい…

          まあ、最初の投稿者の方の話じゃないですが、使っている人自体少ないし使いこなしている人はさらに少ないというのは当たっているかなと思います。

          それはさておき、今手元で動いてるFreeBSD5.1のifconfigのマニュアルを見ると、「こんなの手で書きたくない!」とは思いますね。yaccを使おうというのは正しい選択かなと。
          親コメント
        • kmyacc、今でも時々使ってます。

          bisonやFreeBSDに付属のyaccに比べて、出力するコードがコンパクトだし、
          liby.a が要らないのがUNIX/Win(BorlandC++)でコードを共用するのに便利なもので。
          親コメント
      • Re:yaccは便利 (スコア:2, 参考になる)

        by Sune (7520) on 2003年12月03日 16時57分 (#447036)
        BNFつながりなんですが、まだだれも上げてなかったので書いときます。

        最近C++のboost::spirit [boost.org]という構文パーサにはまっております。
        非常に良く出来た(変態的な)ライブラリで、yaccや組み込みSQLのような別の処理系や
        プリプロセッサを使わず、生のC++コードにEBNFもどきの文法とアクションを直接埋め込んで
        構文・字句解析ができるようになっています。

        yaccとは一味違うEBNFを採用していること、無理やり感のある独特な構文表記、
        Javaに押されぎみでマイナー感が出てきたC++と、いろいろ絡み合って、正にアレゲな感じです。

        複雑な構文を処理するならyacc/flex、そうでないならspiritと使い分けたいのですが、
        もともと少ないC++プログラマで、さらにEBNFが理解できる人があまりいないのが玉に傷。
        興味ある方は選択肢のひとつとして調べてみると良いことがあるかもないかも。
        #yacc++とかはおいかけてないので、よく分かりません
        親コメント
        • Re:yaccは便利 (スコア:2, 参考になる)

          by N'gatt (9815) on 2003年12月04日 1時58分 (#447436) 日記
          参考:ドキュメントの日本語訳 [cppll.jp]

          #まだ途中みたいですが…
          親コメント
        • by Anonymous Coward
          spiritって実用的な時間でコンパイルできますか?
          使ってみてもよさそうだけどGCCと組み合わせたときがどうなるか…
          • Re:yaccは便利 (スコア:2, 参考になる)

            by Sune (7520) on 2003年12月03日 21時51分 (#447207)
            時間はなんともいえませんが、生成処理は yacc + Cより遅そうです。
            C++ + templateなんで、かなりCPUを消費します。

            まだ小規模なとこにしか使っておりませんが、数十~百行程度
            のEBNF構文定義であれば最近のPCでストレスなくコンパイル
            できます、が、それ以上の規模になるとどうなるかわかりません。

            #VC7.1+P4 3GHzなんで、gccを使う場合参考にならないかも

            シンボルテーブルを食い尽くすらしく、デバッグ用のオプションを
            少し弱めに変更しないとうまくリンクできませんでした。

            他に気づいた点で言うと、yaccで生成したものと比べて実行時に
            スタックを消費する傾向があるので、その辺も注意したほうがよいでしょう。

            等価な文法を食わせて統計を取ってみると面白そうですね。
            親コメント
      • by Anonymous Coward

        BNFわからなければRFCも読めませんから当然みんな判ってるはずですよね

        しかしこのストーリーの閑散とした状況(コメント数19)を見ると、そうじゃないんでしょうね。/.Jって、"News for Nerds, Stuff that matter"なんてごたいそうなこと

        • by saitoh (10803) on 2003年12月03日 21時59分 (#447213)
          もともと分かっている人が少ないしね。 yaccが扱えるのは LALR(1)だけど、 大学の情報系学科でも形式言語理論をLRやらLALRまでやってる 学科は日本国内では少ないように思います。

          knuth博士の博士論文って、LR文法じゃありませんでしたか?

          親コメント
          • by mass (8786) on 2003年12月03日 22時19分 (#447231)
            最近はLLのパーサジェネレータの方が流行りみたいですね。
            Perl::RecDescent [ibm.com]にせよ、JavaCC [ibm.com]にせよ。
            JavaCC に関しては必要に応じて先読みトークンの数を増やせるという仕様があるので、
            LALR を使うまでもないことのほうが多いのかもしれませんが。
            親コメント
          • by Anonymous Coward
            大学の情報系学科でも形式言語理論をLRやらLALRまでやってる学科は日本国内では少ないように思います。
            アメリカのきちんとした大学ならどこでも、学部の必修科目ですね(おかげでドラゴンブックの中古はいつでも安く買えます、すごく仰々しい名前の新版が出る予定らしいですが)。

アレゲはアレゲを呼ぶ -- ある傍観者

処理中...