「コンパイラ・スクリプトエンジン」相談室11at TECH
「コンパイラ・スクリプトエンジン」相談室11 - 暇つぶし2ch459:454
07/04/17 18:35:28
>>455-456
流石にそこは真っ先にチェックしてます。

>>457
すみません。字句解析と構文解析を逆に書いてました。
意味解析は今回は必要ないです。

>>458
と、なるとjavaccあたりで行うのが無難でしょうか?

460:デフォルトの名無しさん
07/04/17 18:49:57
構文解析抜きじゃ、メトリックを計れないでしょ


461:デフォルトの名無しさん
07/04/17 18:52:57
意味解析という言葉を持ち出している時点でネタ決定

462:デフォルトの名無しさん
07/04/17 19:10:45
>>461
教科書的には意味解析という言葉はある。

463:デフォルトの名無しさん
07/04/17 19:15:11
意味解析抜きじゃ、コードの質を計れないでしょ

464:デフォルトの名無しさん
07/04/17 21:14:04
すげーな
俺は字句解析と構文解析をわける意味も必要も境目も全く理解できんかった
どう考えても構文解析までやらないとわからんトークンってある気がするっつうか
そうでなくとも構文解析しながらのが略

465:デフォルトの名無しさん
07/04/17 21:22:02
字句解析した方がプログラムとしてまとまりがあってよい。

466:デフォルトの名無しさん
07/04/17 21:24:20
いや、構文解析までやんねーと字句に分けらんねーって話なんだけど

467:デフォルトの名無しさん
07/04/17 21:30:06
cモドキでプリプロセッサとcパートとインラインアセンブラを同時に解釈するような
アホコンパイラを作ったときは字句解析と構文解析が交じり合って酷い目にあったな。


468:デフォルトの名無しさん
07/04/17 21:33:39
こんなん分けていいことないよね

469:デフォルトの名無しさん
07/04/17 21:43:52
>>466
言ってる意味わかんない^^;

470:デフォルトの名無しさん
07/04/17 21:50:26
いやだからさー
字句解析って構文になってない
つまり前後をみないで文字単体で判断することになるわけじゃん
これやりにくいぜー

471:デフォルトの名無しさん
07/04/17 21:53:04
という文法を作るとコンパイルが糞遅い言語が出来上がるわけですな。

472:デフォルトの名無しさん
07/04/17 21:57:40
文字っつうかトークン?

473:デフォルトの名無しさん
07/04/17 21:58:15
>>470
どんな文法でもトークンに分けられますよ。
だから、大丈夫です。

474:デフォルトの名無しさん
07/04/17 22:01:56
いやそれがさ
構文解析までしてみないとトークンとしてわけずらいもんがあるわけよ
できるできないの話じゃなくてな

475:デフォルトの名無しさん
07/04/17 22:03:47
>>474
どの程度までを構文解析って言ってるのか曖昧

476:デフォルトの名無しさん
07/04/17 22:08:30
あいまいも糞も一回でもやってみりゃわかるでしょ
わからない人とはお話ししませんw

477:デフォルトの名無しさん
07/04/17 22:10:30
いや、字句解析・構文解析ぐらいやったことあるけど、普通に棲み分けできるぞ?

478:デフォルトの名無しさん
07/04/17 22:38:34
>>474
> 構文解析までしてみないとトークンとしてわけずらいもんがあるわけよ
> できるできないの話じゃなくてな

それは多分、言語の文法の問題。
CやJavaレベルなら、構文解析までしなくても字句解析は普通に
出来ると思う。

どんな文法の言語の話?
例文希望。

479:デフォルトの名無しさん
07/04/17 22:50:14
こういう曖昧なのとかか?
決め打ちだと思うけど。

#include <stdio.h>
int main() {
int a = 3;
printf("%d", a---3);
}

480:デフォルトの名無しさん
07/04/17 23:19:51
・ゆるいJavaScriptのような、文の後の改行はセミコロン(の省略)とみなされ、
それ以外ではホワイトスペースとして飛ばされるケース(改行文字のトークン解釈が構文解析の状態に依存)
・文字列リテラル中に、埋め込みテンプレートのような感じでその言語の式が書けるケース(字句構造内に構文構造が存在する)
etc.

481:デフォルトの名無しさん
07/04/17 23:23:12
>>480
あ~そうか、君はちゃんとした教育を受けてないんだ。
我流だね?

482:デフォルトの名無しさん
07/04/17 23:26:10
>>479
そういうのもそうだな
あとダブルコーテーションの中身が豪勢なのも俺は嫌いだ
あとなんだったかな
なんかもっと個人的に微妙なんだけど凄く嫌なのあったんだけど忘れたw
今度メモってくる
誰か解決策知ってるかもしれんし

483:デフォルトの名無しさん
07/04/17 23:30:25
改行とかタブとか見えないのが構文に影響を与える言語早く廃れてほしい
パイソンとかもう消えていいよ

484:デフォルトの名無しさん
07/04/17 23:38:42
>>479
a---3 は特に字句解析で困ることはなし。
マイナスが連続した場合の処理だけど、
 1.1つめのマイナスを読み込む。
 2.1文字先読みする。
 3a.2で読んだ文字がマイナスなら演算子--(マイナスふたつ)と判断。
 3b.2で読んだ文字がマイナス以外なら演算子-(マイナスひとつ)と判断。
ってだけで済む。

>>480
眠いから後でよく考えてみるけど、後者の文字列リテラル中に
言語の式が含まれると言っても、その言語の文法すべてを
含めることができるわけじゃない…んだよね?たぶん…

485:デフォルトの名無しさん
07/04/17 23:39:40
>>483
スペースはいいのかね

486:デフォルトの名無しさん
07/04/18 00:01:51
Cだとint *pで(3/*p)だとコメントのエラーになる。
構文解析の段階で字句まで処理しちゃうと
組み合わせの爆発的増大がおきるからやらんだろ。

487:デフォルトの名無しさん
07/04/18 00:06:18
構文まで踏み込まないとわからんトークンがあるから
俺は同時にやっちゃったほうがいいと思うけどね

488:デフォルトの名無しさん
07/04/18 00:12:07
/と*を別々に扱えば良いだけ。

489:なにこのスローモーな会話
07/04/18 00:24:16
>>484
3---a

490:450
07/04/18 00:29:34
>>451-453
どうもありがとうございます
>>451
それちゃいます
>>452-453
それっぽい気もするけどなんか違う気がしました

自分でも探してみましたが見つかりませんでした
どうもお騒がせしました


491:デフォルトの名無しさん
07/04/18 00:37:50
空気

492:デフォルトの名無しさん
07/04/18 00:39:17
>>481 >>481

493:デフォルトの名無しさん
07/04/18 00:43:33
>>481って馬鹿?


494:デフォルトの名無しさん
07/04/18 00:45:40
構文解析までしないとトークンに分けられないオレオレ言語の文法ってどんなのよ。
変数名に記号でも使えるのか?

495:デフォルトの名無しさん
07/04/18 00:46:24
>>493
いえ、彼は大天才です。ただ我々のような凡人には馬鹿にしか見えませんが。

496:デフォルトの名無しさん
07/04/18 00:49:40
>>484 >>481

497:デフォルトの名無しさん
07/04/18 01:51:04
LL文法に後からルールを追加する方法無いかな……
オートマトンを弄くるしか無いかな?

498:デフォルトの名無しさん
07/04/18 02:09:36
>>483
Whitespaceおすすめ

499:デフォルトの名無しさん
07/04/18 02:16:02
ホルホルしてデンパ垂れ流しか

500:デフォルトの名無しさん
07/04/18 07:32:33
>>488
そしたら / * がコメントの開始になるんじゃね?


501:デフォルトの名無しさん
07/04/18 07:42:53
>>478
>CやJavaレベルなら、構文解析までしなくても字句解析は普通に 
>出来ると思う。 
>
>どんな文法の言語の話? 
>例文希望。 

C の typedef で定義された型。

これは確かに「文字列」としては切り出せるが、その後
それがただの識別子であるか typedef された型であるかが
分からないと構文解析はできない
(普通この問題は、構文解析して得た情報を
字句解析側にフィードバックすることで対応している筈)。


502:デフォルトの名無しさん
07/04/18 07:44:16
3/*p コメント開始
3/ *p 正しい式


503:デフォルトの名無しさん
07/04/18 07:50:50
>>501
> 筈

脳内ですね

504:デフォルトの名無しさん
07/04/18 07:58:31
字句解析では、識別子を認識するだけ。
(変数名, 関数名, 構造体/共用体名, typedef名)

狭義の構文解析では、識別子が文法上正しい位置
に出現している事を認識するだけ。

505:デフォルトの名無しさん
07/04/18 08:00:12
>>503
まあな。
俺は誰かさんとは違って、
世の中の全てのCコンパイラのソースを
読んだ経験がある訳ではないからな。

俺が悪かった。
チラシの裏の落書きだと思って読み飛ばしてくれ。


506:デフォルトの名無しさん
07/04/18 08:11:11
(int)("foo", stdout)
はキャストで、
(fputs)("foo", stdout)
は関数呼び出しという問題のことでおk?
この場合必要なのは意味解析から構文解析へのフィードバックであって、
字句解析は関係ないような。

507:デフォルトの名無しさん
07/04/18 08:18:34
より正確に言うと、文法上正しい位置に現れた識別子は、
その文法に従って変数名, 関数名, 構造体/共用体名, typedef名, …
のいずれかの属性が付けられる (仮定される)。

例えば
 a = 3; // aは変数
 b();   // bは関数

変数と仮定した識別子の定義と参照に矛盾がないことを
チェックするのは意味解析フェーズの仕事。

 typedef int integer; // 定義1:integerはtypedefされた型名
 integer a;       // 定義2:a は integer型変数
 a();           // 参照:a は 関数名のはずだったが
              //     定義2と矛盾している→エラー



508:デフォルトの名無しさん
07/04/18 08:19:35
>>505
見たこともない話をくどくど言うのはビョーキ

509:デフォルトの名無しさん
07/04/18 08:24:48
>>506
いったい何処に意味解析の入る余地があるのか全然分からない。

もしかして、"int" という文字列を、
字句解析では int キーワードとして
認識しないつもりなのか?


510:デフォルトの名無しさん
07/04/18 08:29:15
頭悪すぎ。

intは予約語なので、字句解析レベルで認識可能。
(integer)("foo", stdout) ならば、
字句解析で integerは(関数戻り値の)型と仮定され、
意味解析で integerの型定義を確認する

511:510
07/04/18 08:31:09
× 字句解析
○ 意味解析

(integer)("foo", stdout) ならば、
字句解析で integerは単なる識別子
 (変数名、関数名、typedef名、・・・)と認識され、
構文解析で (関数戻り値の)型と仮定され、
意味解析で integerの型定義を確認する

512:デフォルトの名無しさん
07/04/18 08:32:43
>>510-511
ミスは見なかった事にしてあげようw

513:デフォルトの名無しさん
07/04/18 09:22:42
>>489
> >>484
> 3---a

うん。だから、それは
「3」「--」「-」[a」
の4つのトークンに解析されるから文法エラー。

514:デフォルトの名無しさん
07/04/18 09:30:34
>>512
まぁ、そのほうが身の為だよ。
(相手が自分で訂正したミスを意識し続ける奴って馬鹿にしか見えないから)

515:506
07/04/18 09:47:30
>>509
(XXX)("foo", stdout)という形の式を見たときに、XXXが型名(予約語だけでなくtypedef名も含む)か
そうでないかを判断しないとこれ以上構文解析できない、ということを言いたかった。

>>510-511
何を言ってるかさっぱり分からん。
「(関数戻り値の)型」って何?

516:デフォルトの名無しさん
07/04/18 09:50:58
>>507
いい加減なことを言うな。
Cに関数名と変数名の構文的区別はない。

517:なんでこんなに物判りが悪いの?
07/04/18 10:18:50
式 (XXXX)("foo", stdout) の処理方法

字句解析: XXXXは、(変数名、関数名、構造体/識別子、typedef名
のいずれかを表す)識別子トークンとして認識される。

構文解析: 式 (XXXX)("foo", stdout)は、
(少なくとも)2種類の解釈ができる。

 解釈1. XXXXが関数名の場合
   関数XXXXの呼び出しと解釈する。
   XXXX("foo", stdout) と等価。
   ("foo", stdout) は関数の引数と解釈する必要がある。

 解釈2. XXXXが型名の場合
   型XXXXへのキャスティングと解釈する。
   ("foo", stdout) は式と解釈する必要がある。

意味解析: 識別子XXXXの定義を調べ、
 構文解析フェーズのどの解釈が適切か判断する。

但し実際のCコンパイラは1パスでこれを処理するので、
構文解析フェーズで式(XXXX)("foo", stdout)を処理する前に、
XXXXは関数名もしくは型名として定義済みでなければならない。
(未定義のまま参照された場合、未定義エラーとなる)

518:デフォルトの名無しさん
07/04/18 10:19:47
頭が悪いから

519:デフォルトの名無しさん
07/04/18 10:22:13
字句解析時には識別子の種類 (変数名、関数名、構造体/識別子、typedef名) を判断する必要はない。

520:デフォルトの名無しさん
07/04/18 10:28:45
>>516
おまえの質疑応答はいつも高飛車だな
バカ丸出し

521:デフォルトの名無しさん
07/04/18 11:41:21
>>500
字句解析では、「コメントの開始」をトークンとして扱わない

522:デフォルトの名無しさん
07/04/18 11:54:58
ここはひどい揚足鶏スレですねw

523:デフォルトの名無しさん
07/04/18 12:20:36
>>513
何気に勉強になった

>>516
もっとくやしく

>>521
/* ~ */ をスキップ、かな。

524:デフォルトの名無しさん
07/04/18 12:37:15
>>523
> /* ~ */ をスキップ、かな。
そういうのは構文解析の段階でするんじゃないかな

525:デフォルトの名無しさん
07/04/18 12:43:34
それなんて言語?

526:デフォルトの名無しさん
07/04/18 13:01:05
Cって、コメントはプリプロセスの段階で取り除かれるんじゃなかったっけ?

527:デフォルトの名無しさん
07/04/18 13:03:10
>>497
www

528:デフォルトの名無しさん
07/04/18 13:52:55
一ヶ月ぶりに覗いたがなんという成長の無いスレか

529:デフォルトの名無しさん
07/04/18 16:09:44
トークンの座談会の巻

謎の男「やあ伊藤君!」
伊藤君と呼ばれた女の子「そういう君は佐藤君か!」
佐藤君と呼ばれた男「斎藤君はまだ来ないのか?」
斎藤君と呼ばれたネカマ「俺なら既にいるがな!」
後藤君と名乗るネナベ「…俺をシカトするな!」

530:デフォルトの名無しさん
07/04/18 16:56:32
>>529
不覚にも吹いた。


531:デフォルトの名無しさん
07/04/18 20:54:38
>>519
そうすると、構文解析で問題が出る。
例えば変数宣言の箇所で、

a b;

という記述があったとしても、
それが構文上正しいかどうかが分からない。
a が typedef 名ならば正しいが、
そうでないならば構文エラーだろ?

まあ、これを(無理やり)構文解析では ok として、
意味解析に押し付けるという主張もあるようだが、
もし本当にそんな設計をしたら、
まあ、多分グダグダになるだろうな。
だってそれじゃ、構文解析って
実質何の仕事もしてない事になってしまうもの。

・・・まるで、どこかの丸投げ SIer みたいな仕事のやり方だよ。


532:デフォルトの名無しさん
07/04/18 20:57:43
お前は日本語読解力に大きな問題がある事が判った。

533:デフォルトの名無しさん
07/04/18 21:07:37
>>531
「構文」エラーを判定するのは「構文」解析の仕事だと思うのだが?

534:デフォルトの名無しさん
07/04/18 21:15:52
>>533
>「構文」エラーを判定するのは「構文」解析の仕事だと思うのだが? 
もちろん、そのとおり。

・・・で、一体何処に突っ込んでいるの?


535:デフォルトの名無しさん
07/04/18 21:21:41
おこちゃまむけせつめい

(1)ていぎぶのしょり1
  "typedef int a;"
字句解析くん:  予約語(typedef)、組込み型(int)、識別子(a) ";" キター
構文解析さん:  typedef文キタワァ・・・組込み型(int)、型識別子(a) って感じ?
意味解析先生:  型テーブルに登録しときますね。

  型識別子|型
  --------+-------------
  a     |int

(2)ていぎぶのしょり2
   a b;
字句解析くん:  識別子(a)、識別子(b)、";" キター
構文解析さん:  変数宣言みたいな感じぃ?
           でも 型(a)って定義されてるのかしら
(意味解析先生: 型テーブルを見ればいいのに・・・)
構文解析さん:  型テーブルに型(a)って書いてあるわね
           じゃあ答は 型(a)、識別子(b) ね。
意味解析先生: (よしよし) 変数テーブルに登録しときますね。

  変数識別子|型
  -----------+-------------
  b       |a


536:デフォルトの名無しさん
07/04/18 21:22:40
低レベルな人間の自作自演はいつまでたっても話が解決しないので、チョー笑える

537:デフォルトの名無しさん
07/04/18 21:41:15
そもそも「意味解析」って、入力データが
"構文的に完全に正しい" という事が判明した「後」の話だろ?

まず、そこら辺の常識、知ってるのか?


538:デフォルトの名無しさん
07/04/18 21:42:09
糖質か。スルー

539:デフォルトの名無しさん
07/04/18 22:02:23
意味解析持ち出したアフォに話を合わせといたら、
ついにアフォが自分の掘った穴にはまったなw

変数テーブルや型テーブルの管理は、
構文解析の仕事だよ
yaccで言うと、BNFを構成するの
それぞれの構文要素にアクションとして記述する

540:デフォルトの名無しさん
07/04/18 22:03:08
管理っつか、登録と参照ね

541:デフォルトの名無しさん
07/04/18 22:26:50
>>539
> 変数テーブルや型テーブルの管理は、
> 構文解析の仕事だよ

「ふつうは」それらは意味解析の仕事だよ
Cなどの言語では構文の都合上本来は意味解析でやるべき
仕事を構文解析でやらざるを得なくなってるだけ
そりゃもちろんyaccのアクションにそれらの仕事を押し込む
ことはできるけど、言語が複雑になればなるほど
そういうことするとメンテナンス性が下がる

それと、亀レスだが構文解析レベルでなければ処理しづらいトークンの
例としては、上でも誰かが挙げてた文字列リテラルの中に式を埋め込める
構文(Rubyの#{...}など)で十分だろう。この場合、字句解析器は埋め込み式の
ネスト構造を認識しなければならないので、字句解析と構文解析を完全に
分離するとうまく対処できない(字句解析では一般的に、正規表現を使って
トークンを表現するため)

542:デフォルトの名無しさん
07/04/18 22:30:02
字句くん:構ちゃんがいつも相談してもらってる先生って、ホントは構ちゃんの一人二役でしょ?
 ホンモノの意味先生は忙しいから、そんな雑務に付き合うわけないし

構文さん:当たりでーす てへへ

543:デフォルトの名無しさん
07/04/18 22:30:49
>>539
>変数テーブルや型テーブルの管理は、 
>構文解析の仕事だよ 
>yaccで言うと、BNFを構成するの 
>それぞれの構文要素にアクションとして記述する 

アクションとして記述する部分は構文解析の範疇じゃないだろ?
構文解析と言えば、

・構文的に正しいか否かを判別すること
    yacc で言えば、{ } 内の処理が全くない状態で
    parsing できるか否かを判別すること。

・正しい場合、それがどの構文形式かを一意に特定すること
    >>517
    >構文解析: 式 (XXXX)("foo", stdout)は、 
    >(少なくとも)2種類の解釈ができる。 
    こんなのダメダメ。実質、reduce/reduce conflict だろうが。

だろ?


544:デフォルトの名無しさん
07/04/18 22:32:46
>>441
ありゃ。スミスさんが来た予感。

545:デフォルトの名無しさん
07/04/18 22:33:40
> こんなのダメダメ。実質、reduce/reduce conflict だろうが。

それでは正しい解説をどうぞ。


546:デフォルトの名無しさん
07/04/18 22:35:03
>>534
字句解析に対して構文解析の仕事を要求しているように読解できたんでな。
まあ、漏れの読解力不足かもしらん

547:あらあらまたハッタリかな
07/04/18 22:35:49
> こんなのダメダメ。実質、reduce/reduce conflict だろうが。

それでは正しい解説をどうぞ。



548:デフォルトの名無しさん
07/04/18 22:41:28
>>537
C言語の場合は実質 >>517, >>535だろ。
それが気に入らないなら、
C言語使うのヤメるか、

    自分でコンパイラ書けばいい。

毎度毎度のお話だが。

>>541
言語内のミニ言語(埋め込みSQL、Cのプリプロ、printfフォーマット等)なら
別の言語エンジンで解析するのがデフォだろ
eval絡みのリテラルなら、言語エンジンを再帰的に適用するとか。

549:デフォルトの名無しさん
07/04/18 22:41:57
>>547
もしかして、ダメダメだってことが
"本当に" 分かってないの?

BNF による ANSI C の定義なんて、ネット上に
いくらでも転がっているのに?


550:デフォルトの名無しさん
07/04/18 22:43:08
あのさぁ、素人向け解説にいちいちマジ突っ込みするのって、
それなんて名前の火病?

このスレの惨状、レベルの低さを見てから、
ちゃんと回答を丁寧に示せ。お前の義務だ

551:逃げちゃダメだよ
07/04/18 22:43:44
> こんなのダメダメ。実質、reduce/reduce conflict だろうが。

それでは正しい解説をどうぞ。


552:デフォルトの名無しさん
07/04/18 22:45:12
>>550
話もろくにかみ合わない糖質相手にマジんなんな

553:デフォルトの名無しさん
07/04/18 22:47:18
>>548
>C言語の場合は実質 >>517, >>535だろ。 

じゃあ、
URLリンク(www.bookshelf.jp)
とか読む限りでは、GCC なんて異端児だな。


554:デフォルトの名無しさん
07/04/18 22:47:42
火病だ(プゲラ

555:デフォルトの名無しさん
07/04/18 22:56:26
「gccでは二種類のトークン 識別子 と typedef型名 を扱っており、
 字句解析と構文解析が連携して動作する」

きちっと言えばこれだけの話だろ。
ところでスレの話の本筋は意味解析がうんたらかたらになっちゃっている。
じゃあまず話の筋がおかしいって指摘したらどう?

物事を丁寧に説明できない人種には
あまり関わりたくはないなあ




556:デフォルトの名無しさん
07/04/18 22:59:57
reduce/reduce conflictを避けたら、
lexical tie-inが必要になっちゃいましたぁ

557:デフォルトの名無しさん
07/04/18 23:02:52
>>555
こんな時間帯にここに常駐してる人間に
そんなクオリティを求めるのはムリだ

558:デフォルトの名無しさん
07/04/18 23:03:25
>555
>きちっと言えばこれだけの話だろ。 

それは >>555 の思い込みに過ぎない。
俺が言いたいのは「これが一般的な処理方法だ」という事。


559:デフォルトの名無しさん
07/04/18 23:06:15
あーうるせー
俺のいない間にスレ進み過ぎだろ
全部読むのに苦労したぜ

結局さ、字句解析と構文解析なんてわざわざ分けるだけ面倒なだけでしょ

俺が週末に趣味で作ってるスクリプト言語が完成するまで
反論は一切許さない
このスレにくるたび最良の方法が目移りしてなかなか作業が進まない罠

年内に公開はもう無理だと思うw

560:デフォルトの名無しさん
07/04/18 23:08:36
> それは >>555 の思い込みに過ぎない。
> 俺が言いたいのは「これが一般的な処理方法だ」という事。

「一般的」・・・これまた脳内でしょ
なんでいつもハッタリかますの?

561:デフォルトの名無しさん
07/04/18 23:09:05
字句くん: 構ちゃん、俺と結合しようぜ

構文さん: (結婚前はダメ
         ・・・でも身体が反応しちゃうの)

字句くん: あ”なんか身体に入ってきた・・・♂かよ!

562:デフォルトの名無しさん
07/04/18 23:09:27
>>548
>eval絡みのリテラル

具体的な例が思い付きません ><
先生、教えて下さい ><

563:デフォルトの名無しさん
07/04/18 23:09:59
>>560
ググってページ示すのがやっとで
内容理解できない人だからしようがないw

564:デフォルトの名無しさん
07/04/18 23:14:40
キーワード:ダメダメ
発言者:  ダメダメ業務コンサル

565:デフォルトの名無しさん
07/04/18 23:18:00
>>560
まあな。 
俺は誰かさんとは違って、 
世の中の全てのCコンパイラのソースを 
読んだ経験がある訳ではないからな。 

俺が悪かった。 
チラシの裏の落書きだと思って読み飛ばしてくれ。 


566:デフォルトの名無しさん
07/04/18 23:18:12
結局LISPが最強ってことか。

567:デフォルトの名無しさん
07/04/18 23:19:29
キーワード:ダメダメ
発言者:  ダメダメ業務コンサル
発言:    まあな。
俺は誰かさんとは違って、
世の中の全てのCコンパイラのソースを
読んだ経験がある訳ではないからな。

俺が悪かった。
チラシの裏の落書きだと思って読み飛ばしてくれ。

Web石碑に登録完了しました

568:デフォルトの名無しさん
07/04/18 23:24:30
>>567
で、結局、意味解析に任せるのが
「正統派だ」ということでいいのか?


569:デフォルトの名無しさん
07/04/18 23:25:05
>>548
541だが、俺が例に出した式を埋め込める文字列リテラルというのは、
そのミニ言語がその言語自身なわけで、もう1つ言語エンジンを作るのは
無駄でしょ。しかも、その埋め込まれた式が構文的に間違っていたら
構文解析エラーを出す必要があるから、言語エンジンを再帰的に適用する
なんて方法でもダメ

で、実際はどうするかというと、状態付きLexerにして、ParserからLexerの状態を切り替えるか、
そもそもLexerとParserを分ける必要が無い構文解析アルゴリズム(Packrat Parsingなど)を
使うわけだ

570:デフォルトの名無しさん
07/04/18 23:32:02
>>568
宗教選択じゃねぇんだから、目的考えて自分で解決しろ。
スミスっぽい方が >>569に来てるから、相談したらどうよ。

>>569
> 構文解析エラーを出す必要があるから、言語エンジンを再帰的に適用する
> なんて方法でもダメ

ダメな理由をkwsk


571:デフォルトの名無しさん
07/04/18 23:39:32
Packrat Parsingで効率良いパーサ書けますって言いたいだけじゃないか、とw

Packrat Parsing: Simple, Powerful, Lazy, Linear Time. Bryan Ford. ICFP 2002.
URLリンク(pdos.csail.mit.edu)

で具合はどうよ


572:570
07/04/18 23:45:25
> 構文解析エラーを出す必要がある
から
> 言語エンジンを再帰的に適用する
なんて方法もダメ

前段と後段がつながらないね。
エスケープ文字の問題?

エスケープ文字を処理済みの式を
構文チェック・モードの言語エンジン (≒Lexer+Parser)
で再帰的に処理して、構文解析エラーを出せば済む


573:デフォルトの名無しさん
07/04/18 23:50:37
左再帰を人手で除去するのがめんどい

574:デフォルトの名無しさん
07/04/19 00:04:04
>>572
すまん。よく考えてみると、言語エンジンを再帰的に
適用する方法で行ける気がしてきた。ただ、その方法は
煩雑になるんじゃないかなあ(特にParser Generator
を使う場合、面倒そうな気が)。

>>571
> Packrat Parsingで効率良いパーサ書けますって言いたいだけじゃないか、とw
まあ、半分くらいはそのような意図が無いでもない

> で具合はどうよ
これはどういう意味?

575:デフォルトの名無しさん
07/04/19 00:06:29
>>531
遅レスだが。

丸投げするような仕事は、
そもそもSIer内部で誰も興味ない
つまらない仕事だから丸投げ&ピンハネするだけだろう

本筋をちゃんと説明せず
関係ない話でお茶を濁すのは
醜いよ

576:デフォルトの名無しさん
07/04/19 00:16:18
> > で具合はどうよ
> これはどういう意味?

ェェェエエエエエエ
そこでこっちに投げるか?普通
たとえば
・バックトラックやconflictを避けた素直なパーサを書きやすいか
・処理時間がリニアで高速か
とかそんな話じゃなかったっけ

ちゃんと見てないけど

577:デフォルトの名無しさん
07/04/19 00:31:06
なんでおまいら今日に限ってこんなにスレ消費が速いんだよwwwwwwwwww

578:デフォルトの名無しさん
07/04/19 00:46:26
>>576
ああ、そういう意味ね。具合はどうかという言葉の意味を
この場合どう取ったらいいかちとわからんかったもので

で、長文になるけど、Packrat Parsingに対するコメントとしては

・複雑な字句構造を持った言語のパーザは非常に書きやすい
・LL(k)やLR(k)と違って、選択される要素の並び順に意味があるので、
そこは注意する必要がある(A / B / CはA / C / Bとは意味が違う)
・単純な字句構造の言語だとかえって書きづらいことがある(空白文字や
コメントの処理も構文解析レベルで処理する必要があるため。ただ、
これは字句解析後のトークン列をPackrat Parsingで解析すればいい
という話もある)
・処理時間はリニアだけどLL(k)やLR(k)アルゴリズムに比べると低速な
ことが多い。ただ、これはナイーブなPackrat Parsingの話で、Parser Generator
を使うこと前提なら、Parser Generatorに色々な最適化を組み込むことはできる
と思う
・アルゴリズムの特性上、構文規則の書き方で性能がかなり変化する
(選択(/)が上から順番にマッチングを行うようになっているため)

579:デフォルトの名無しさん
07/04/19 08:15:19
e ::= x | n | e + e | e * e
+, *は左結合で、優先度は* > +

みたいな構文はpackrat parserではどう書けるの?

580:デフォルトの名無しさん
07/04/19 21:10:32
演算子順位文法かよ
そんなん手書きでもできるだろ

581:デフォルトの名無しさん
07/04/20 00:04:14
>>531-580
おまんまんらめえーまでよんだ

582:デフォルトの名無しさん
07/04/20 00:12:23
残りもちゃんと読めよ。読み終わるまで夕食抜きな。

583:デフォルトの名無しさん
07/04/20 00:37:28
おまえら無駄に加速し過ぎる

584:デフォルトの名無しさん
07/04/20 00:42:14
>>582
おまんまんらめえー
らめなの!そんな太いの入るわけ無いじゃない!
500kバイトのソースファイルなんて私には無理!
い…いや!ひぃー
(ギチギチ)
あ…あたまがおかしくなっちゃうの…
もう駄目…オーバーフローして…しまう
「」さん…ごめん…げふ

585:デフォルトの名無しさん
07/04/20 00:52:57
>>579
基本的にはLL(k)の場合と同じく、左再帰を除去して、
優先順位ごとに構文規則を作る必要がある。>>579の例だと
こんな感じ
e ::= a ('+' a)*
a ::= p ('*' p)*
p ::= x | n
Packrat ParsingはParsing Expression Grammar(PEG)ベースの
構文解析アルゴリズムだから厳密には
e <- a ('+' a)*
a <- p ('*' p)*
p <- x / n
のようになるけど(<-とか/はPEGで使われる記法)

586:デフォルトの名無しさん
07/04/20 19:43:46
>585
なるほど。
parseして抽象構文木を作ろうとした時、元の文法だと自然にできるけど(e + eとか)、
packrat版だとやりづらそうだね。

587:デフォルトの名無しさん
07/04/20 20:23:42
えええええええ?記法が異なるだけじゃん。

588:デフォルトの名無しさん
07/04/20 20:23:48
彼女がエッチさせてくれません・・・
みなさん、エッチする前はどういう風に切り出していますか?
アドバイスください

589:587
07/04/20 20:25:40
なんだ、頭がおかしい人が来てるだけか

590:デフォルトの名無しさん
07/04/20 20:34:31
>>589
ねえ、なんでそんなに頭が悪いの?

591:デフォルトの名無しさん
07/04/20 20:40:13
>>586
そうね。
ただ関数クロージャを使えば上手くやれる

592:デフォルトの名無しさん
07/04/20 20:40:15
キミの話にはいつも具体性がない。
アフォはアフォなりに、隅っこで小さくなってろ。

593:デフォルトの名無しさん
07/04/20 20:44:58
どんな解釈してるのやら。
基礎が無い奴って話が特異点だらけで萎えるな

594:デフォルトの名無しさん
07/04/20 20:46:08
おまえら、アンカーつけろよ。
誰が誰に言ってるのかさっぱりわからん。

595:デフォルトの名無しさん
07/04/20 20:47:35
ネカマ乙

596:デフォルトの名無しさん
07/04/20 20:50:32
実際にコードにするときはパーサコンビネータやらパーサジェネレータやらを使う訳で、
そのときに左結合の式を解析するための要素が用意されていればいいのだから、
実際にはそれほど問題じゃないかな?

597:デフォルトの名無しさん
07/04/20 20:56:00
Parsing Expression Grammars: A Recognition-Based Syntactic Foundation
URLリンク(pdos.csail.mit.edu)
URLリンク(pdos.csail.mit.edu)

Abstract

For decades we have been using Chomsky's generative system of
grammars, particularly context-free grammars (CFGs) and regular
expressions (REs), to express the syntax of programming languages and
protocols. The power of generative grammars to express ambiguity is
crucial to their original purpose of modelling natural languages, but
this very power makes it unnecessarily difficult both to express and
to parse machine-oriented languages using CFGs. Parsing Expression
Grammars (PEGs) provide an alternative, recognition-based formal
foundation for describing machine-oriented syntax, which solves the
ambiguity problem by not introducing ambiguity in the first
place. Where CFGs express nondeterministic choice between
alternatives, PEGs instead use prioritized choice. PEGs address
frequently felt expressiveness limitations of CFGs and REs,
simplifying syntax definitions and making it unnecessary to separate
their lexical and hierarchical components. A linear-time parser can be
built for any PEG, avoiding both the complexity and fickleness of LR
parsers and the inefficiency of generalized CFG parsing. While PEGs
provide a rich set of operators for constructing grammars, they are
reducible to two minimal recognition schemas developed around 1970,
TS/TDPL and gTS/GTDPL, which are here proven equivalent in effective
recognition power.


598:デフォルトの名無しさん
07/04/20 20:59:39
>>597
そんな有名論文をいまさら貼って何がしたいんだ?

599:デフォルトの名無しさん
07/04/20 21:03:34
なんだよ。
>>585-586のつながりがあまりに不自然だったんで、
なんか変な荒しかと目を疑っちまったよ。
(e + e)=左再帰除去の話ね。了解

600:デフォルトの名無しさん
07/04/20 21:39:11
発言は幼く、態度は横柄

こりゃとんだ学生さんだなw

601:デフォルトの名無しさん
07/04/21 00:42:24
基礎がないから、何もかもが特殊な話に見えるのだろう。
見ていて恥ずかしくなる。

602:デフォルトの名無しさん
07/04/21 00:58:02
たぶんここで聞くのがいいか判らないのですが、

自分で正規表現を実装してみようと思ったのですが、BNFみたいな仕様書はどこに
あるのでしょうか?RFCの何千番台目ぐらいですかね?

603:デフォルトの名無しさん
07/04/21 01:02:29
底抜けのマヌケだと思った。


604:デフォルトの名無しさん
07/04/21 01:44:00
NFA ヌンチャク・ファイティング・アーツ

無形無限流ヌンチャク術を武道スポーツとして、
「誰にでも安全かつスマート」に指導しています。
NFAでは男性、女性、大人、子供と全てが活躍中!
また、NFA精神と無形無限流の技法で、
他流派武器術大会にも積極的に参戦中です!
左動画 無形無限流演武 NFA代表 宏樹

605:デフォルトの名無しさん
07/04/21 11:16:42
>>604
DFA ドラゴン・ファ……
の方が強そうだぞ


606:デフォルトの名無しさん
07/04/21 19:35:52
>>602
特に仕様書というのはないと思う。
あるのは、PerlやRubyといった各言語ごとの仕様書。
PHPなんて2種類の正規表現が用意されているし。
RFCもないだろうから、好きなように実装すればいいと思うよ。

607:デフォルトの名無しさん
07/04/21 19:39:06
以上、自問自答でお送りしました

608:デフォルトの名無しさん
07/04/21 19:49:00
Internet Engineering Task Forceが正規表現の標準を決めるという発想に度肝を抜かれたw

609:デフォルトの名無しさん
07/04/21 19:57:00
POSIXで一応決まってなかったっけ

610:デフォルトの名無しさん
07/04/21 20:02:56
公開識別子 ISO/IEC 9945-2:1992//NOTATION POSIX Regular Expression Notation//EN は、 POSIX で規定されている正規表現という記法を表します。この公開識別子は ISO/IEC 10744:1997 で使われています。

611:デフォルトの名無しさん
07/04/21 20:08:40
The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
9. Regular Expressions
URLリンク(www.opengroup.org)


612:デフォルトの名無しさん
07/04/21 21:39:37
ちょっと質問です。
C++で動的にルールを変更できるパーザて存在します?
自分でプッシュダウンオートマトン組むしか無いのかな……


613:デフォルトの名無しさん
07/04/21 21:42:06
>>612
パーサとコンパイラコンパイラを混同して無いか?

614:デフォルトの名無しさん
07/04/21 23:39:00
シチュエーションをきちんと説明しないあたり、
また意味ありげに素人妄想口走ってるだけだろ。

615:デフォルトの名無しさん
07/04/22 09:23:20
>>612
「動的にルールを変更」ってのは具体的にはどうしたいの?
こんなルールからこういうルールに変更したい、とか書いとけば
誰か答えてくれるかも…


616:デフォルトの名無しさん
07/04/22 09:48:15
>>612がきちんと問題定義するまで、
ヒント与えちゃダメだよ >> All

こいつは問題定義を明確にせずに
議論をかき回す常習犯だからw

617:デフォルトの名無しさん
07/04/22 10:12:42
これくらいエスパーしてやれよ
お前ら役立たずだな

618:デフォルトの名無しさん
07/04/22 10:24:14
ほら来た半島人

619:デフォルトの名無しさん
07/04/22 10:26:57
掲示板で乱射事件起こしまくりのチョンw

620:612
07/04/22 11:57:00
あらら、なんかもめてますね。ごめん。

C++で俺言語作っているんだけど、どうせならForthやLispみたいにソース読み込み時の
挙動についても言語内に取り込んで拡張できるようにしたいなぁ、と考えたのが背景。

Lispのリードマクロとか、Forthみたいなスペース区切り必須にしてもいいけど、文脈自由文法に
対応できたらいいなぁ。でも、自分で動的に変更可能なLexer & parser作るのも大変だなぁ。
有り物でどっかないかな……

ということで質問しました。


621:デフォルトの名無しさん
07/04/22 16:42:16
個人的には字句解析と構文解析は分離していないと困る。
現実的外人の作ったスケルトンの上での文字コードサポートとか考えるとね。

622:デフォルトの名無しさん
07/04/22 16:42:42
Forthの例は知らないけど、
Lispのリードマクロはプリプロセッサ程度の事しか
やってないんじゃないかな。

文法を動的に変更できる言語というと、
例えばXSD&XMLが思い浮かぶけど・・・

セマンティックへの対応付けまで考慮すると
Lispみたいに自己記述可能な言語や、
JavaVMみたくByteCodeでセマンティックを記述可能な言語じゃないと
難しいような気もする。

623:デフォルトの名無しさん
07/04/22 16:45:09
>>621
それぞれの目的に合った方法を選択すれば良いのだと思う。

上の流れは、単に最近話題になっている
PEG(Parsing Expression Grammer)では
Lexer-Parser分離が不要っていいたかっただけなのだと思う。

624:デフォルトの名無しさん
07/04/22 17:51:56
Caper作った人待ちかな

625:デフォルトの名無しさん
07/04/22 18:03:18
lemonの問題点:

ケーパーよろしこ。

・衝突に厳しい
・tokenがunionなんでコンストラクタ/デストラクタが掛けない

626:デフォルトの名無しさん
07/04/22 18:47:28
動的な変更は、ユーザー定義の中置演算子を導入する等を行う方法と
Dylan,Nemerle等のマクロが有名です。


627:デフォルトの名無しさん
07/04/22 18:53:07
なんか勘違いしてる雰囲気がする

628:デフォルトの名無しさん
07/04/22 21:12:22
要するに、動的パーサというよりは
マクロ・プロセッサーが欲しいという事?

629:626
07/04/22 21:31:16
動的パーサってことは、要するにマクロ・プロセッサー
ってことなんじゃと思って書いきました。勘違いしてたらゴメン。
というか、動的パーサのいい方法あったら、
マクロプロセッサに使えそうなので俺も知りたいです。


630:デフォルトの名無しさん
07/04/22 21:47:35
>622
Lispのリードマクロは文字の読み込みもできるので、やろうと思えば色んなことができますな。
ここ以上のことはしらんけど。
URLリンク(user.ecc.u-tokyo.ac.jp)
こんなネタもあんのか。
URLリンク(www.geocities.co.jp)

Forthの場合は、各命令(Word)に、ソース読み込み時に実行するかどうかを設定する
Immediate属性というのがあって、これを活用すると色々なリテラルを設定することができる
ようになるらしいです。
マクロみたいなもんだけど、ForthはWordを基本とする言語だから、これで何でもできるようになる
……らしい

まあ、どっちにしろLexer&Perserは自分で組まなきゃいけないね。


> XSD&XML
「タグを使った入れ子構造」というルールは変更できたっけ?

>628
いや、動的パーザ。
今はboost::spiritで文法を書いているんだけど、これを俺言語から文法を修正・改造できるようにして、
自己拡張的にしたいと考えてます。

やっぱり自分でオートマトンを書き換えるようにするのかなぁ……


631:デフォルトの名無しさん
07/04/22 22:07:07
長文どかどか書く奴がろくな事を言った試しがない。

632:デフォルトの名無しさん
07/04/22 22:09:00
> どっちにしろLexer&Perserは自分で組まなきゃいけないね。

Lispはそれはねぇな

> > XSD&XML
> 「タグを使った入れ子構造」というルールは変更できたっけ?

タグを使った入れ子構造≒構文解析木
という標準的な解釈で、構文木の文法ルールを変更できるだけだよ。
常識ねぇな


633:デフォルトの名無しさん
07/04/22 22:10:22
>>630
んーと、「動的パーザ」って一般的な言葉なのかな…?
(無知ですまん)

で、630が欲しい機能は動的に制御構造を定義できることでいいのかな?
となると、Lispのリードマクロよりもdefmacroとかのほうに近いような…

Lispの場合、すべてがS式だから、リードマクロやdefmacro等で、
制御構造を定義できるけど(パーザはS式が読み込めればいいだけ
なので単純にできる)、C/C++などの系統の言語だと、制御構造を
動的に定義可能にするのはかなりむずい気がする。

最初から、言語の文法を考えるときに動的に拡張できる文法を
考えながらじゃないと無理なんじゃないかな。

LispにしろForthにしろ、もともとの文法が単純だから
制御構造の拡張なども出来るんだと思う。

634:デフォルトの名無しさん
07/04/22 22:12:11
> 今はboost::spiritで文法を書いているんだけど

それってしょせん再帰下降文法だろ。
文法ノードを一個一個関数で書いてくだけだ。
ならその関数自体をスクリプトで書いて、
下位の文法要素の呼出組み替えられるようにすれば
文法カスタマイズ完成だな。

大した手間じゃねぇ~じゃん

635:630
07/04/22 22:14:25
>>633
変な勘違いすんな。
なんかやりてぇって言ってるのは>>612
よく読めスットコドッコイ。

ほんと半島人はガッついてて大変だな

636:デフォルトの名無しさん
07/04/22 22:15:27
>>631
ほんと長文書く奴来ると、
途端にレベルが低下するんだよな

637:デフォルトの名無しさん
07/04/22 22:29:44
>>636
長文書くヤツってようは自分の言いたいことも簡潔に
まとめることができない馬鹿だからねぇ、仕方ないよ。

638:デフォルトの名無しさん
07/04/22 22:36:00
長文書く奴がどうこう以前に、
このスレは一度たりともレベルが高くなったことがないと思うが。

639:デフォルトの名無しさん
07/04/22 22:37:39
みんなごめんね☆

何か寂しくなっちゃってしってる事ぜんぶまとめて長文で書き込みしちゃいました。

反省したので明日ボウズにしてきます。

(;_;)

640:638
07/04/22 22:38:49
みんなごめんね☆

何か寂しくなっちゃって自分の内的な願望を書き込んじゃいました。

反省したので明日ボウズにしてきます。

(;_;)

641:デフォルトの名無しさん
07/04/22 22:39:32
>>638の節穴っぷりにワロタ

642:626
07/04/22 22:40:46
そ、それは、凄く核心的。
いわば、コンパイラ・インタプリタで動的に文法変えられるパーサライブラリですね。
リードマクロ発動を含む基本となる文法を定義してあとはインタプリタは知らせればOK
ってあれば、いいなぁ。

再帰下降でちょちょって書いたパーサなら各文法の関数呼び出し部分を
関数ポインタを介して呼び出すようにしておいて、フックできたら、似たようなことできるかなぁ。


643:デフォルトの名無しさん
07/04/22 22:41:22
あれの動的文法生成インターフェイス、動的解釈テーブル構築エンジンって
他の言語にも使いまわせないのかねぇw

644:633
07/04/22 22:41:28
>>635
勘違いでしたか。すまん。

>>612とLispのリードマクロがどうも頭の中で結びつかなくて、
変な妄想がはいったみたい。

645:デフォルトの名無しさん
07/04/22 22:42:37
>>641
お前はいつこのスレでレベルの高さ感じたんだよ。

いってみろ。そうしたら節穴はお前だってことがはっきりするんで。

646:デフォルトの名無しさん
07/04/22 22:43:24
>>642
ぉぃぉぃ

きみの目も節穴なのか

647:626
07/04/22 22:44:02
>>642>>630のレスです。
書いてるうちにずいぶんスレが進んでた。orz...

648:626
07/04/22 22:45:28
>>646
節穴なんですね。。。どうして?節穴なのでしょうか?


649:デフォルトの名無しさん
07/04/22 22:46:45
理想:comp.lang.compilers
現実:fj.news.usage

650:デフォルトの名無しさん
07/04/22 22:47:18
646は口が節穴なので、テキトーな口からでまかせが出るだけです。

651:デフォルトの名無しさん
07/04/22 22:47:49
とりあえず、俺自身の話はおいといて。
このスレにはパーサジェネレータ自分で書くレベルの人と、
なんかForth自慢やLisp知識自慢で満足しちゃえる程度のレベルの人が
混在している事が判った。

おもしろいよキミ達

652:デフォルトの名無しさん
07/04/22 22:48:37
すずきぃ、おまえやっぱレベル低いわ

653:デフォルトの名無しさん
07/04/22 22:49:14
スレのレベルが低いのはここにいる全員の責任だ。
みんな、共に精進していこうじゃないか。

654:デフォルトの名無しさん
07/04/22 22:50:12
レベルの高い人がタマにしか来なくて、
あとは貧民階級ばっかの気がする。(って変なの1人くらいか)

655:デフォルトの名無しさん
07/04/22 22:51:39
>>651
名言。いや、判っててネタ振りしてるのかと思ってたよ今まで

656:デフォルトの名無しさん
07/04/22 22:53:24
>>643
そうだね。とりあえずアレが一番の手がかりだ。
早速なかを確認してみるよ

657:デフォルトの名無しさん
07/04/22 22:55:16
>>652
禿同

658:デフォルトの名無しさん
07/04/22 23:01:43
LLパーサのカスタマイズ方法すら判らなかったとは傑作だな。
ソース読めてないんじゃないか、と。

659:デフォルトの名無しさん
07/04/22 23:04:23
LLはN.Worthのデータ+アルゴリズム・・・のPL/0で学んで、
その後は惰性で書けるようになるのがデフォだ

・・・ってboost::spiritの中の人もそれっぽい事ゆってたw

660:612=620=630
07/04/22 23:25:38
何でこんな荒れているんかね?騙りも出て来たし。これだからIDの無い板は……
GW前なのに5月病かね?
>632 だから文法を弄りたいんだって。
>634 ちょ、オマ……。オートマトンを書き換えるのと手間変わらないんじゃない?
>658 オートマトン組むLL perser generatorてC++であったっけ? 具体例は?

>633
>「動的パーザ」って一般的な言葉なのかな…?
いいや。そもそも見たことないから質問している訳で……

>defmacro
defmacroは“ソースはS式”という前提があるけど、ここではそういう制限も無しにしたい、と
いうのが背景にあります。

>LispにしろForthにしろ、もともとの文法が単純だから制御構造の拡張なども出来るんだと思う。
まあね。ただ、俺言語の文法&挙動定義も俺言語から指定できたらなぁ、と思って。
カスタマイズだけでもできるようになると面白いよね。

>642
そうそう、そんな感じ。
最初はForthみたいな文法だけど、その内(文法を上書きして)CなりRubyなりLispなりに
文法が変わっていく感じで。

>644
>635は荒しだから気にすんな。
Lispのリードマクロ = (S式じゃなくて)ソースを解釈する というイメージですな。


661:626
07/04/22 23:31:40
どうせ、ワタシャ貧困層の馬鹿ですよ。うえーん(;_;)

662:デフォルトの名無しさん
07/04/22 23:31:46
LLにせよLRにせよ、与えられた文法規則からLookaheadを計算することによって
解析アルゴリズムの導出が可能になるわけで、動的に文法が変わったらLookahead計算し直し、
あるいはPackratやSyntactic Predicate等、任意長の先読みができるように最初からしておくとかしか無いわな。

663:デフォルトの名無しさん
07/04/22 23:37:47
>>660って、もしかしてblogにASTの事書いてた人かな。

664:612
07/04/22 23:40:07
>662
簡単にするんだったら
・受理状態じゃないと文法書き換え不可
・その時のLookaheadはステ
あたりかな?


665:612
07/04/22 23:42:00
>663 違う、違う。誰と間違えているのか知らないけど、おいらじゃないよ。

666:デフォルトの名無しさん
07/04/22 23:44:26
あやしい…

667:デフォルトの名無しさん
07/04/22 23:44:48
>>660 >>662
お、なんか核心突けそうな人が来たー


>>660
>>634否定して、>>642持ち上げるって事は、
「Forthライクになんとかしたい」って結論で固まってるのかな。
意図が判らない。

あと、>>612を読んで
caperの「動的文法生成インターフェイス、動的解釈テーブル構築エンジン」
ってのを改造できればいいのかな?と考えた。

なんか意図がつかみにくいスレだな

668:デフォルトの名無しさん
07/04/22 23:47:49
(プッシュダウン)オートマトンだから
Forthマンセーって所か。

LALRパーサならプッシュダウンオートマトン使ってなかったっけ?
(すげぇ不安になってきた・・・)


669:612
07/04/22 23:49:46
>662
……良く考えたら、そんな簡単な話じゃないな。
少なくとも、最上位のルールが受理状態でないとダメですな─うわ、かなり限定的だなぁ
Lookaheadを捨てるだけでも何とかなりそうな気がするけど、どういう挙動になるか判らない……


670:635
07/04/22 23:57:43
>>660
騙るつもりはなかったんだが、
スレ番読み間違えたようだ
その件はスマン。他には騙りなどしていないよーん


671:デフォルトの名無しさん
07/04/23 00:02:05
>>668
PDA(Push-down automaton)はただの概念上の、入力テープ上を逆戻りできなくて、テープを書き換えることもできないけど、スタックのついたチューリング機械。
LLはPDAのLeftmost derivationの順方向を、LRはPDAのRightmost derivationの逆方向をそれぞれシミュレートするアルゴリズム。
LALRはLRの改良版。

>>669
文法を途中で書き換えるっていうんじゃ、その度に構文解析表なりなんなりをまるごと構築しなおさないと。
少なくともPDAってのは静的な生成規則に基づいた機械だから、別の方法を使うなら、もはやPDAではないものになるんじゃないかと。
つーか、受理状態のときのみどうのこうのってのは、あんま意味がわからんが、いわゆるトップレベルでのみ文法操作が可能ってこと?

672:デフォルトの名無しさん
07/04/23 00:03:43
これって一種のリフレクションとも言えるよね。
オブジェクトレベル(解釈されるもの)であるソース文字列がメタレベル(解釈するもの)であるパーサの
解釈の仕方を動的に変更するという点で。
こういうシステムを作るときは、オブジェクトとメタの切り分けと、メタへのインタフェースをきっちり定義しないと
ドツボにはまるだけ。
問題は、まだ構文木にもなっていない解析前の文字列が、パーサを変更できるほどの表現力を持てるかどうかだ。

673:668
07/04/23 00:04:46
うん、それは判ってる(はず(汗))

あなたが仰るとおり、>>669が何故PDAに拘るのか、
それがよく判らないだけだ(はず(汗))

うーん、言語処理系に対するイメージってのは
人それぞれなんだなぁ。もっと人の発言を大切にしなきゃ(荒しは除外)

674:デフォルトの名無しさん
07/04/23 00:13:06
>>672
リードマクロ関数の書き換え程度の小さな文法変更ならともかく、
大規模な文法変更ってのは、あんま段階的にやるような類の話じゃないんじゃないかな。
カエルの変態じゃあるまいし。

コンパイラの世代みたいな感じで、
最初は核(つーか初期値)となるパーサで文法変更関数読んで、
構文木かVMコード内部に溜め込んで、
その関数実行したらどーんと文法変わるという
サナギ方式が使いやすいとオモタ

675:デフォルトの名無しさん
07/04/23 00:18:54
>>671
> PDA(Push-down automaton)はただの概念上の、入力テープ上を逆戻りできなくて、
> テープを書き換えることもできないけど、スタックのついたチューリング機械。

逆戻りも書き換えもできるだろ。


676:612
07/04/23 00:27:33
>667 >>634否定して、>>642持ち上げるって事は、
いや、否定してないよ。LLぐらいはサポートしたいから、最後の手段としては考えているけど……

>caperの「動的文法生成インターフェイス、動的解釈テーブル構築エンジン」

今から作るとしたら、caperをベースにするのが分かり易そうですな。
caperカスタマイズしてPDA吐き出すようにして、ルール変わるたんびに再構築
といった感じかな……さすがに遅そう……
それとも複数文法持てるようにして、切り替え命令で文法を切り替えるようにするとか。
>674の指摘している方法もいいね。


677:612
07/04/23 00:29:27
>671 その度に構文解析表なりなんなりをまるごと構築しなおさないと。
やっぱりそうだよな……既にあるオートマトンにくっ付けるだけじゃダメそうだよね……
>もはやPDAではないもの
PDAを元にオートマトンを書き換えるのならば、それはもうTMだよね。
ちなみに、PDAはTMじゃ無いよ。TM相当は2スタックマシンね。

>受理状態のときのみどうのこう
受理していない場合は受理しない可能性が残っているから、受理していない情報を元に
オートマトンを組み換えるのは不味いよね。
決定性PDAなら単にエラーになるだけだけど、非決定性PDAだと他の受理状態の可能性が
あるからね(バックトレースが発生して書き換え自体がキャンセルされる)

>672
>ドツボにはまるだけ
それはそうだね。ただ、趣味の俺言語なんで、馬鹿みたいな柔軟性を用意してみようかと……

>パーサを変更できるほどの表現力を持てるかどうかだ。
ここはForthみたいにImmediate属性を導入するという手もあるね。
そもそもコアの部分はソースを読み込む前に使用可能になっているから、そこから
組み上げていくのが良さそう。

>675 逆戻りも書き換えもできるだろ。
できないよ。できるとしたらTMか2スタックマシンのどっちかだね。

じゃ、そろそろ寝ます
ノシ

678:デフォルトの名無しさん
07/04/23 00:29:58
>>675
堂々と嘘つくでねぇ。
思わず本棚から言語理論の本引っ張り出してきちまったよ。

679:675
07/04/23 00:42:51
あいすんませんね

後でチェックし直しときます

680:デフォルトの名無しさん
07/04/23 01:11:17
動的な文法とやらを文脈依存文法で定義してみたらどうだろう?とか言ってみたりして

681:680
07/04/23 01:14:39
と思ったけど、構文解析がPSPACE完全になっちまうか
なんか制限つけたら軽くなるのかな?

682:デフォルトの名無しさん
07/04/24 01:55:59
なんかGW中の勉強にとLLパーサ(BNF?)自前で作りたいんだけど
何かいい課題になる題材ないでしょうか?

683:デフォルトの名無しさん
07/04/24 02:38:09
>>682
URLリンク(www.kmonos.net)

684:デフォルトの名無しさん
07/04/24 06:22:39
LISP最強

685:デフォルトの名無しさん
07/04/24 17:51:52
Lispパーサなんか作ってもたいした勉強にならんだろ

686:デフォルトの名無しさん
07/04/24 17:57:20
スレのレベルが急速に低下しました・・・

687:デフォルトの名無しさん
07/04/24 19:03:21
「このスレは一度たりともレベルが高くなったことがない」
とか思ってる人が暴れてるだけだろ
スルーしておけ

688:デフォルトの名無しさん
07/04/24 19:20:24
人の所為にすんなボケw

689:デフォルトの名無しさん
07/04/24 20:34:38
しょうがないよ、現実を歪めてまで
お前のせいではないと主張する理由が無いものw

690:デフォルトの名無しさん
07/04/24 21:23:25
↑全部こいつの妄想か。

691:デフォルトの名無しさん
07/04/24 21:51:38
孤軍奮闘w

692:626
07/04/24 22:01:04
なんかしらんけど、俺が言いたかったのはこういうことでした。
var exp = function() {
var m;
if(m=str.match(/^[0-9]+/)) {
str = str.substring(m[0].length);
return m[0];
}
throw "error";
};
parse("1+2");
で1が戻るようなもので
var fact = exp;
exp = function() {
var c = fact(); var m;
while(m = str.match(/^\+/)|| m =str.match(/^\-/)) {
str = str.substring(m[0].length);
c = [m[0],c,fact()];
}
return c;
};
alert(parse("1+2"));
で、["+",1,2]がかえるように出来るというかんじ。
URLリンク(f38.aaa.livedoor.jp)
実際動くのはこんな感じ。

693:デフォルトの名無しさん
07/04/24 22:07:26
何を言いたいの君は?
相変わらず話題とずれてるな

694:デフォルトの名無しさん
07/04/24 22:37:09
再帰下降パーサがやっと理解できました、
と言うだけの話なら「よく頑張りましたね」って
ポジティブな方向に持ってけるんだけど、


おまえの場合スレ荒しまわって「このスレレベル低い」
までほざいた挙句に、いけしゃーしゃーと初心者発言開始するから
嫌われるんだよ。
いい加減にしとけクズ

695:デフォルトの名無しさん
07/04/24 22:40:19
目の前の人間と仮想敵をごっちゃにして
わけのわからない呪文みたいな罵倒する奴増えたなぁ。

696:デフォルトの名無しさん
07/04/24 22:45:43
まあいいんじゃない?そんな仮想敵にムキにならなくても

このスレの現実は
匿名なら何やってもいいと思っている身元バレバレの性格破綻者も居れば、
このスレのお陰で再帰下降パーサ書けるようになった>>626も居るって事。

メデタシメデタシ

697:デフォルトの名無しさん
07/04/24 22:51:27
なんだ。桜井さんが来てたのか。

698:デフォルトの名無しさん
07/04/24 22:51:32
「このスレはレベルが低い」って言ってる人は、
本音としては「お前らレベル高すぎるから、もっと優しくしてくれ」と泣き言を言っているだけだろう。

素直にそう言えばいくらでも対処してくれる人が居るだろうに、
いちいち相手を高飛車に叩いて初心者質問を繰り返すから敬遠されるわけだが

699:デフォルトの名無しさん
07/04/24 23:08:49
どっちかというと、スレのレベルが低くなったとか言うアホが問題。

700:デフォルトの名無しさん
07/04/24 23:10:23
ねぇMatz、信仰者にもいろいろなタイプが居るんだね。

701:デフォルトの名無しさん
07/04/24 23:14:45
なんでmatzが出てきたの?

702:デフォルトの名無しさん
07/04/24 23:16:20
国内でも最高レベルの技術的知名度を持つ信仰者と
人間として最低レベルの信仰者が同じスレに存在する不思議さ

それが2ちゃんねる

703:デフォルトの名無しさん
07/04/24 23:24:14
モデレーターがいて肩書き出す、そういう場でなくて
2ちゃんでなければならぬ理由は
直接民主制への夢を棄てるべきではないから。
2ちゃんでなければ意味がない。

704:デフォルトの名無しさん
07/04/24 23:29:49
そういう話は別の板でやってくれ。
お前の話はいつもズレズレなんだ

705:デフォルトの名無しさん
07/04/24 23:31:02
>>703
はっきり言っておまえ統合失調症だろ。
お前の会話や文章の支離滅裂さは
見ていて頭が痛くなる

706:612
07/04/25 00:11:57
>680
それLBAじゃないと解釈できない……つうか万能TM作っているようなもんじゃない?
そもそも有効な記法てあったっけ?


707:626
07/04/25 01:05:34
>>693
再帰下降の出来上がったパーサを拡張するのに、
こういう風にやったらいいんでないってことの具体例を書いたのだけど。

>>694
ん?「このスレレベル低い」なんていったことないですよ。
凄いレベル高い人達が多くて、いつも怒られてると思ってたんですけど。

ほんとは、caperみたいなものが作れたらいいなぁ思ってるけど
作れないしわからないので、理解できる範囲で書いたのだけども。

匿名掲示板は知らないこと聞くにはありがいですが。
でも、それ以外は辛いことが多いですねぇ。
俺は、躁鬱病で統合失調障かも知れないとこまでいってしまってたり、
統合失調症で苦しんでる人もしってるから、辛い。
まぁ、2ch用語だから、ジョークなんだろうけど。
ちょうどいい、匿名でないコンパイラのこと話せる掲示板ってないのかなぁと
思う今日この頃ですよ。

708:デフォルトの名無しさん
07/04/25 01:11:35
この違和感はいったい何なんだろう。
例えるなら……そう、一人だけ全然違うこと喋ってるみたいな。

709:デフォルトの名無しさん
07/04/25 01:52:18
荒らしているのが一人だけというのがよくわかった

710:デフォルトの名無しさん
07/04/25 02:12:18
やったね!

711:612
07/04/25 02:40:38
>707
再帰の関数をクロージャかオブジェクトにしてプラガプルにするのが王道じゃない?
突き詰めるとboost::spiritのオブジェクト版になると思うけど……


712:デフォルトの名無しさん
07/04/25 06:40:04
要するに、彼はようやく再帰下降パーサとは何か理解できたって事だ

713:626
07/04/25 09:39:58
>>711
すでに、そういう概念あるんですね。
プラガプルって言う概念はググっても出てこないのでよくわからないんですけど。
ちゃんと話についていけるようになりたくて、ドラゴンブックみても、わからん。
鬱出し脳な、今日この頃です。笑

714:626
07/04/25 10:07:14
plug ableってことで、挿入可能みたいなかんじですかね。

715:デフォルトの名無しさん
07/04/25 11:40:41
いいから貴方達はRats!(URLリンク(www.cs.nyu.edu))を見てから
出直してきたまえ。

716:デフォルトの名無しさん
07/04/25 12:00:52
またリンク貼るだけのお前か。
何を主張したいのか、簡潔に要約しろ。

717:デフォルトの名無しさん
07/04/25 12:33:05
とても興味深いね。
ここでやっていたようなお話を
Robert Grimm氏がxtc(eXTensible C)として
研究している、という事か。
Rats!に関してはどうよ?

718:デフォルトの名無しさん
07/04/25 17:10:20
>>716
「ちゃんと書かれていることはわかるけど、まだ自分には理解できない」
ページを持ってきて、自分もまたそのレベルにあるように見せるのはよくあることです。

719:デフォルトの名無しさん
07/04/25 18:23:06
初歩的な質問ですみません

文法G=(P,S)
   P={S→(L)|a
     L→L,S|S}

これの終端記号って、”,”も含まれるんですか?

720:デフォルトの名無しさん
07/04/25 19:53:47
>>719
含まれる

721:デフォルトの名無しさん
07/04/25 19:56:07
>>720
ありがとうございます。

722:デフォルトの名無しさん
07/04/25 20:25:39
もう一つ

文法G=(P,S)
P={S→AB
  A→aAb|b
  B→bBc|ε }
の言語はどんなものか。

という問題なんですが、どう答えたらいいんでしょうか・・・問題の意味がよく分かりません

723:デフォルトの名無しさん
07/04/25 20:54:10
>>722
文字abcがどんな風にならんだ文法か、ってことじゃないかな…
ヒントだしすぎ?

724:デフォルトの名無しさん
07/04/25 21:05:33
言われてみれば、実に微妙な表現だなぁ……w

725:jonigata
07/04/25 22:25:13
ごめんあんまり見てなかった。

動的なルールだけど、
caperは実際に起動時に動的なルール構築を行って
読み込みファイルの文法を定義しているので、
そのソース使いまわせばできるよ。
一応caperとは独立したものとして作ったので、
普通に切り出せると思う(確かlalr.hppとgrammar.hppだけあればよかったような)。
実際の文法定義例はcaper_cpg.[hc]ppのmaker_cpg_parser。

ただ文法定義のインターフェイスが
自分でもよく間違うようなあまりよくないものなので、
ちと工夫しないとまずいかも。

あと内部でSTLバリバリ使ってるので、それも注意。

726:デフォルトの名無しさん
07/04/25 22:50:16
>>723
つまりこの問題だと
a,b,cがこの順に複数個ずつ並んだ文 って感じでいいんですかね・・・
言語はどんなものってどういう問題なんだ(´・ω・`)

727:デフォルトの名無しさん
07/04/25 23:24:23
>>726
> 言語はどんなものってどういう問題なんだ(´・ω・`)

求められているのは、文法表記からどのような文法になってるのかを
読み取る能力。

この問題だと単に文字abcの並びでしかないが、このabcが
また別の文法ルールだとしたらどうだろう?
そしてその文法ルールには、さらに別の文法ルールが…
ってな感じでどんどん複雑な文法に接するようになると思うけど
今はまだはじめたばかりだろうから、焦らずじっくり取り組むといいと思う。


728:727
07/04/25 23:30:40
追記。

最初から、if文や算術演算なんかの文法を教えるよりも
文字の並びという単純なところから教えるほうが
「if文とはなにか」「+-*/の演算の意味」なんかを
教えなくてもいいという利点があるのかな。たぶん。

すでになんらかの言語でプログラムしたことのある人にとっては
かえって意味不明に感じるかも知れないけどね…

729:デフォルトの名無しさん
07/04/25 23:31:48
>>722
>>726
文字aがn回連続して並ぶというのをa^nと仮に表記するとして、
a^m b^(m + n + 1) c^n (m >= 0, n>= 0)
という条件を満たす言語。a,b,cが順に複数個並んだ文、だけだと条件が
不足してる

730:デフォルトの名無しさん
07/04/25 23:59:21
packrat parsingってLALR(1)と具体訂にどんな違いがあるの?


731:デフォルトの名無しさん
07/04/26 02:28:38
>>727
焦らずじっくりだと間に合わなかったりしてw

732:デフォルトの名無しさん
07/04/26 05:41:24
>>730
complexity

733:デフォルトの名無しさん
07/04/26 16:51:03
“Stop the World”を防ぐコンカレントGCとは? (1/2) - @IT
URLリンク(www.atmarkit.co.jp)


734:デフォルトの名無しさん
07/04/26 23:29:06
だいぶ今更な記事だな...

735:デフォルトの名無しさん
07/04/26 23:49:01
パーサー書くときのコーディングのテクニックが掲載された書籍は存在するのでしょうか。


736:デフォルトの名無しさん
07/04/27 00:58:05
今年ってコンパイラに関係する本って出版される予定ないんだな...


737:デフォルトの名無しさん
07/04/27 09:49:51
C/C++のプリプロセッサの構文やマクロ展開アルゴリズムが載ったページや本とかないでしょうか?
あとVCとGCCで使えるマクロの違いが分かるものも探しています。

たとえば、↓のマクロはGCCでは使えて、VCでは使えません。
 #define MSG(format, param...) printf(format, param);
こんなのが分かるものを探しています。


738:デフォルトの名無しさん
07/04/27 13:50:20
>>737
>C/C++のプリプロセッサの構文やマクロ展開アルゴリズムが載ったページや本とかないでしょうか?
URLリンク(gcc.gnu.org)
このへん?

>あとVCとGCCで使えるマクロの違いが分かるものも探しています。
処理系固有の拡張は処理系のマニュアルに載っているはず。

それから、スレ違いじゃないか?

739:デフォルトの名無しさん
07/04/27 13:55:29
Cのプリプロセッサ作りたいなら、このスレでもいいのでは?
コーディングのテクニック載ってる本あったら買うだろうなぁ。

740:デフォルトの名無しさん
07/04/27 18:07:38
誰かの自作自演が始まると、
ガクッとレベルが低下するな
このスレ

741:デフォルトの名無しさん
07/04/27 19:30:22
同意

742:デフォルトの名無しさん
07/04/27 19:34:00
まったくだ

743:デフォルトの名無しさん
07/04/27 19:48:08
仰る通り

744:デフォルトの名無しさん
07/04/27 20:45:24
>740はいつも正しいな

745:デフォルトの名無しさん
07/04/27 21:31:14
>>737
最近プログラミング始めたとかだとその辺
情報足りてないよね…

Cプリプロセッサ・パワー―C言語の秘められた能力を解き放つ(1988年発行)
URLリンク(www.pro.or.jp)
>マクロについて勉強したければ、標準のヘッダーファイルとか、
>ウィンドシステムなどのヘッダーファイルなどに豊富な例があるので、
>そちらを参考にした方が、はるかにためになるでしょう。

というか日本には20年前に出版されたのしかないのね…orz
ソース嫁。もしくはググれ。20年前にはググれなかったわけだし。

プリプロセッサとは - はてなダイアリー
URLリンク(d.hatena.ne.jp)

この辺からマクロっぽいことやってるのを追いかけてみるのも
有効かもね。

alias, エリアス, スクリプト言語とかやってることまんま
マクロっぽい気がする。微妙にスレ稚貝っぽいのでsage。

>>736
書籍の価値って何なんだろうね。出版されるのは入門書ばっかりだよね。
どうでもいいけど。
>速効! Pythonプログラミング バージョン2.5対応
>URLリンク(www.shuwasystem.co.jp)

746:デフォルトの名無しさん
07/04/27 21:36:53
プリプロセッサのプログラミング解説と言えばカーニハンが書いた有名な本があるだろ…

747:745
07/04/27 22:44:51
>>746
マクロ カーニハン で 検索
URLリンク(d.hatena.ne.jp)
URLリンク(www5a.biglobe.ne.jp)
URLリンク(www.coara.or.jp)
URLリンク(www.pro.or.jp)

ありが㌧。なんか基本中の基本みたいでした
これだからゆとりは orz

748:デフォルトの名無しさん
07/04/27 23:03:08
言うまでも無い事だが、マクロ・プロセッサーのソースが載っているカーニハンの本と言えば
「ソフトウェア作法」 URLリンク(www.amazon.co.jp)
の方だw

記述言語&ターゲット言語はFORTRAN

749:デフォルトの名無しさん
07/04/27 23:06:48
×マクロプロセッサ
○プリプロセッサ

www

750:737
07/04/27 23:30:10
いろいろと情報ありがとうございます。
C言語の仕様に則したプリプロセッサを作ろうと考えているのですが、
738のPredefined macroとかを見てると完全準拠は難しそうですね・・・
とりあえずたくさんのソースをパースしてみて
1つ1つクリアしていこうかと思います。

>>746
カーニハンの名著って「プログラミング言語C」でしょうか?
同じカーニハンの「プログラミング作法」では関数マクロは使うなみたいなことが
書いてあるらしい(Amazonより)のでプリプロセッサが嫌いなのかと思いました。


751:デフォルトの名無しさん
07/04/27 23:40:54
>>750
> 同じカーニハンの「プログラミング作法」では関数マクロは使うなみたいなことが
> 書いてあるらしい(Amazonより)のでプリプロセッサが嫌いなのかと思いました。

「プログラミング作法」のほうだと思う。
ただし、「プログラミング作法」に載ってるのはFortran用の
プリプロセッサーの話。
Cのプリプロセッサーではないので注意。

752:745
07/04/28 01:00:12
プログラミング作法 第1章「スタイル」関数マクロはなるべく使うな etc
URLリンク(www.ascii.co.jp) (2000/11)
 ↑
プログラム書法 (プログラミング作法の前版 記述言語は Fortran,PL1)
URLリンク(d.hatena.ne.jp) (1982/06)
プログラム書法 メモ
URLリンク(www.6809.net)
 ↑
ソフトウェア作法 使用言語 は RatFor (1981年)
Ratfor - Wikipedia
URLリンク(ja.wikipedia.org)

発刊された年順に並べるとsoft作法->prog書法->prog作法

soft作法(Fortran) -> orz
prog書法(Fortran,PL1) -> prog作法(C)

あれっ、soft作法はアップトゥデートされてなwwwww

こんなかんじですた (調べるのめんどい)

753:612
07/04/28 01:41:25
自己フォロー。 boost::spirit v1.8 にstored_parserなんていうのがありました。
正しく求めていたのですな。こんなことができました。ソースコードベタはり

#include <iostream>
#include <conio.h>
#include <boost/spirit.hpp>
#include <boost/spirit/dynamic.hpp>
#include "main.hpp"
using namespace boost::spirit;

template<typename ScannerT>
class TSetToken {
public:
   TSetToken(boost::spirit::stored_rule<ScannerT>& target) : target_(target) {}
   void operator()(const char* begin, const char* end) const {
      target_
         =  target_.copy()
         | str_p(begin, end)
         ;
   };
private:
   boost::spirit::stored_rule<ScannerT>& target_;
};

754:デフォルトの名無しさん
07/04/28 01:43:06
おっと、誤)stored_parser 正)stored_ruleですな。

struct TProgramGrammar : public grammar<TProgramGrammar> {
   template <typename ScannerT>
   struct definition {
      boost::spirit::stored_rule<ScannerT> program, block;
      definition(TProgramGrammar const& self) {
         program
            =  +block
            ;
         block
            =  '(' >> (+alpha_p)[TSetToken<ScannerT>(block)] >> ')'
            ;
      };
      const stored_rule<ScannerT>& start() const { return program; }
   };
};

int main() {
   {
      TProgramGrammar p;
      std::cout << parse("a", p, space_p).full << std::endl; // false
   } {
      TProgramGrammar p;
      std::cout << parse("(a) a", p, space_p).full << std::endl; // true
   }
   std::cout << "Press any key" << std::endl;
   getchar();
   return 0;
}



最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch