「コンパイラ・スクリプトエンジン」相談室6

「コンパイラ・スクリ ..

620:デフォルトの名無しさん
05/06/26 00:25:28
>>604
おまぃLisp屋を騙ってる素人だろ。
Lispはプログラムとしていきなり構文木書かせるから、
文法パーサ(yacc, bison, Rie)はｲﾗﾈェ～んだよ

だから、「コンパイラ/スクリプトの話題に文法パーサはｲﾗﾈェ」
プログラミングに精通してる人向けのジョークなんじゃねぇ？
;; あ、素人の人には判らない話だから、
;; そこの人、ムキになって否定しないように・・・

621:デフォルトの名無しさん
05/06/26 00:31:50
>>620 が素人なのはよくわかった。

622:デフォルトの名無しさん
05/06/26 00:32:51
はいはい、わかったわかった（苦笑

623:デフォルトの名無しさん
05/06/26 00:34:45
別に文法パーサって言葉自体はいいだろ。
ただし、yaccなどのジェネレータを「文法パーサ」と言ってしまってるから
誤解を生むってこと。
なお、googleで検索してる奴はほっとけ。

624:デフォルトの名無しさん
05/06/26 00:36:46
URLﾘﾝｸ(en.wikipedia.org)

625:デフォルトの名無しさん
05/06/26 00:38:46
>>624
で？ｗ

626:デフォルトの名無しさん
05/06/26 00:42:29
いいですか～

yaccはパーサではありません。
yaccはパーサを作ってくれるものです。

はい、ここ！試験に出ますよ～
良い子は覚えておきましょうねぇ～

627:デフォルトの名無しさん
05/06/26 01:14:56
>>626
foo.yを解釈するパーサと言えなくもないけどな

628:デフォルトの名無しさん
05/06/26 01:41:04
俺の頭はパッパラパーさ(parser)！

629:デフォルトの名無しさん
05/06/26 02:09:28
>>619
旧DragonBook。
あれを読んでたのは大学のころだな。みんなで輪講して、手でLR(0)itemを列
挙して、lookaheadを求めて、表を作成して…とかやった覚えがある。

ところで、LRパーサーの生成方法を知りたいの？
それともyaccの使い方を知りたいの？
前者だったらやっぱりDragonBookを熟読。読んでるだけでは意味不明でも、
簡単な文法(足し算だけの電卓プログラムとか)のLR表を手で生成して
みるとわかってくるよ。

後者ならO'Reilly本で足りるでしょう。

630:デフォルトの名無しさん
05/06/26 05:31:33
>>627
yacc全体をそうは言えない。パース以外の仕事もするから。

631:デフォルトの名無しさん
05/06/26 10:31:04
「パーサ＝構文解析器」だから「文法パーサ」って馬から落馬系じゃなければ
*.yなどの文法をパースするパーサのこと。
609の「文法パーサ・ジェネレータ」は「コンパイラ・コンパイラ・コンパイラ」って意味だな。

632:デフォルトの名無しさん
05/06/26 14:18:10
yaccは内部にパーサを持ってはいるんだろうけど、
lispはパーサが要らないんだ！って文章を強引に正しくするために
それを持ち出すのは苦しすぎる。

633:デフォルトの名無しさん
05/06/26 14:21:07
yaccは、*.yをパースしたあと、その情報を使って
新たなパーサを作り出すツールであって、
ただ仕事の過程でパーサを使ってるだけ。
だから、yacc＝パーサとは普通いわないし、誤解を生むだけ。
間違ってるといえるかもしれない。

634:デフォルトの名無しさん
05/06/26 21:28:17
yaccはパーサージェネレーターだろ

635:デフォルトの名無しさん
05/06/26 21:30:42
lisp　にはパーサは要らないって言っているけど、
「んじゃパーサ無しでどうやってS式をパースするんだい」　って話になるんだけどどうしよう

636:デフォルトの名無しさん
05/06/26 21:31:30
>>629
ちょっと横レスすまんが、

> 旧DragonBook。

って何？新ドラゴンってあるの？
それとも２１世紀本のこと？

> 後者ならO'Reilly本で足りるでしょう。

どうだろうね。俺もその本持ってるけど、
あんまり役に立つとは思えないんだけど。

637:デフォルトの名無しさん
05/06/26 23:05:19
相変わらず変なのが粘着してるスレだな。

638:デフォルトの名無しさん
05/06/27 00:20:14
>>636
初版は1977年、もう絶版だから今の若い人は知らんか。

Principles of Compiler Design
Alfred V. Aho, Jeffrey D. Ullman
Addison Wesley
ISBN 0-201-00022-9

Amazonにも画像が無かったが、ぐぐってみたら
URLﾘﾝｸ(www-users.cs.york.ac.uk)
の上から二番目にあるな。

639:デフォルトの名無しさん
05/06/27 04:44:46
ああ。その本なら随分前に培風館から出ていたな、Winston Lisp第一版と同じシリーズで

640:636
05/06/27 21:02:19
>>629
失礼いたしやした。
大変参考になりやした。

m(_ _)m

641:デフォルトの名無しさん
05/06/28 21:23:10
素人です。

相乗り質問で恐縮ですが、LALR(1) の１って先読みトークンの数ですよね？
このことは、YACCにシフトされているシンボルの数の最大値が１ということにはつながらないのですか？

642:デフォルトの名無しさん
05/06/28 21:26:35
素人です。

>>641
知りません。

643:デフォルトの名無しさん
05/06/28 21:27:41
っていうかマジレスすると

＞YACCにシフトされているシンボルの数の最大値が１

は合っているんだっけ？

644:デフォルトの名無しさん
05/06/28 22:19:16
ヒロシです。
分からんとです。

645:デフォルトの名無しさん
05/06/29 00:10:28
>>641
そうです。
LR(k)、LL(k)のkは、高々k個の先読みでパースできる文法(のクラス)を表しています。

646:619
05/06/29 06:55:18
>>629

> 旧DragonBook。
> あれを読んでたのは大学のころだな。みんなで輪講して、手でLR(0)itemを列
> 挙して、lookaheadを求めて、表を作成して…とかやった覚えがある。

情報ありがとうございます。
でも、もう手に入らないんですね。

> ところで、LRパーサーの生成方法を知りたいの？
> それともyaccの使い方を知りたいの？
|
> 後者ならO'Reilly本で足りるでしょう。

パーサー自体の生成方法までは、とても考えが及びません。

目的としては、後者です。だとすると、
やはり、O'Reillyの本が定番なんですかね。

入手して、若い頃のようにじっくり勉強してみたいと思います。 (^^;
ありがとうございました。

647:デフォルトの名無しさん
05/06/29 07:47:49
>>646
O'ReillyってLALRの説明まではしてなかったような。
とりあえず使いたいならO'Reillyでいいけど、
yaccを使いこなしたいなら、LALRをきちんと勉強したほうがいい。
コンフリクトしたらシフト優先とか、
自分で変な書式の式を追加するときに、%left とかがどう動くのかとかは
LALRを知らないと理解できない。

648:デフォルトの名無しさん
05/06/29 08:05:26
>>641
LALR(n)だと、
「シフトするトークンは１つだけど、n個先読みしてからシフトするか還元するか決める」
という考え方と
「最大n個シフトしてみて、ダメだったらシフトしなかったことにして還元する」
という考え方ができそう。

649:デフォルトの名無しさん
05/06/29 12:40:16
LALR(k):　k-token LookAhead, Left-to-right parse, Rightmost-derivation,
LL(1):　　　Left-to-right and Left-most Parsing

650:デフォルトの名無しさん
05/07/01 21:58:05
>>647
で、貴方のお勧めは？

651:デフォルトの名無しさん
05/07/02 21:06:34
りん（ry

652:デフォルトの名無しさん
05/07/02 21:52:02
……………　く　ず　れ　す　……………

653:デフォルトの名無しさん
05/07/04 19:03:27
>>652
恐らく lisper w

654:デフォルトの名無しさん
05/07/04 20:28:29
↑間違いなくアンチLISPer ｗ

655:デフォルトの名無しさん
05/07/04 21:55:27
……………　き　ち　が　い　ね　ん　ち　ぁ　く　ち　う　。　よ　う　ち　ゅ　う　い　……………

656:デフォルトの名無しさん
05/07/05 00:54:08
>>655
お前が一番の粘着だw

657:デフォルトの名無しさん
05/07/06 21:55:12
VC++でlexファイル(lex.yy.c)をコンパイルすることはできますか？
Windows版のflexとbisonは見つけたんですが、よく考えたら
gccで-ll(flexなら-lfl)オプションを付けないとコンパイルすることができない・・・

そもそも、gccがlflで何を取り込んでいるのかがわからず。
windowsでflex&bisonを使っているひとがいれば、教えていただけないでしょうか。

658:デフォルトの名無しさん
05/07/06 21:58:34
>>657
lfl　は付けなくても平気。中に入っているのは確か　main　関数だけだった筈だから

659:デフォルトの名無しさん
05/07/07 12:19:19
>>657 >>658

yywrap()も入ってるよ。
以下の関数定義をどっかに入れれば大丈夫。

int yywrap(void)
{
return 1;
}

660:デフォルトの名無しさん
05/07/09 18:00:12
PHPやPerlでは、変数を $var のように表します。
「$」と「var」のあいだにはスペースを入れることができません。
ということは、字句解析でトークンに分解するときに、「$」と「var」の2つに分解するのではなく、
「$var」というひとつのトークンとして認識しているのでしょうか。
（字句解析が「$」と「var」の2つに分解すると、間にスペースを入れられると思うから。）

「$var」を認識するのに、字句解析で1つのトークンとして認識するのがいいのか、それとも
2つに分解して構文解析時に「$var」であると認識するのがいいのか、迷ってます。

661:デフォルトの名無しさん
05/07/09 18:26:38
>>660
1トークンでいいと思うが。2トークンにするメリットが特に見当たらんし。

662:デフォルトの名無しさん
05/07/09 20:03:51
１トークンと考える方が不自然。
２トークンでしょう。(Perl/PHPのソース確認してないけど)

理由：
1. Perlの場合、変数名の前に異なるプリフィクスを使う場合がある。
　　　例)配列宣言　　　@array、　配列参照　　　$array[index]
　　　　　連想配列宣言　%assoc、連想配列参照　$assoc{key}
　左側(配列コンテキスト)と、右側(スカラーコンテキスト)を、異なるトークンと認識したら、
　変数名管理上、トークンからプリフィクス(@, %, $)を外した名前を切り出す必要があり、
　トークンの扱いとして不自然。

2.プリフィクス(@, %, $)と、識別子(var, array, assoc)の間に空白を許すか否かは、
　単なる構文定義上の問題であり、２トークンで空白を許さない定義が可能。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　いじょ

663:デフォルトの名無しさん
05/07/09 20:23:45
PHPに@や%ないじゃん

664:660
05/07/09 20:27:10
>>661
ありがとうございます。そんな気はするんですが、いまいち確信がなくて。

>>662
1.の場合でも、プリフィックスと変数名は別々に渡しませんか？
今はトークンを取得する関数gettoken()と、文字列を取得する関数getvalue()を用意していて、次のようにしています。
入力　　　gettoken()　　　　　getvalue()
------------------------------
'foo'　　　STRING　　　　　　"foo"
100　　　INTEGER　　　　　"100"
3.14　　　DOUBLE　　　　　"3.14"
x　　　　　NAME　　　　　　　"x"
$var　　　VAR_SCALAR　 "var"
@var　　 VAR_ARRAY　　"var"
%var　　　VAR_ASSOC　　"var"

（最後の2つはつけくわえてみました。）
特に不自然ではないと思うのですが、どうでしょう。自信もないですが。

2. について、「2トークンで空白を許さない」ためのうまい方法がよくわかりません。
よろしければ教えてください。

665:デフォルトの名無しさん
05/07/09 20:34:41
空白もトークンとして切り出せ

666:デフォルトの名無しさん
05/07/09 21:59:11
>>665
空白をトークンにするぐらいなら、プリフィクス込みでトークン切り出して、
プリフィクスを取り除いたシンボル名でシンボルテーブル検索した方が
楽だと思うけどなぁ。

まぁ、どっちでも動けば構わんので、あとは趣味の問題だが。

667:デフォルトの名無しさん
05/07/09 22:27:32
>>663
PHPにも
$hoge = 1;
$varname = "hoge";
echo $$varname; // => 1

とかあるけどな！

668:デフォルトの名無しさん
05/07/09 23:13:32
Perlで$$は、ポインターの値参照だったっけ

669:デフォルトの名無しさん
05/07/09 23:38:16
ああ、そうか。

Perl5 だと参照使えるから ${$foo->{'a'}} なんてのもアリなんだな。それだと
確かに字句解析レベルではプリフィクスとシンボル名を分けた方が無難だ。

670:デフォルトの名無しさん
05/07/10 00:40:01
>>665
ええっー、空白をトークンとするんですか。
構文解析がかなり面倒になるんですけど。

>>669
「$」のあとに英数字が続けば変数名、それ以外なら「$」であるというのじゃだめでしょうか。

671:デフォルトの名無しさん
05/07/10 00:44:50
>>664
了解。１トークンで充分だと思う。

Perlの

672:671
05/07/10 00:46:02
>>664
了解。１トークンで充分だと思う。

Perlの $って、Cのポインタ演算子みたいな扱いするから、誤解した。

673:デフォルトの名無しさん
05/07/10 00:47:00
>>670
そもそも「Perl5 のようなスカラー・配列・ハッシュ、さらにその参照を任意に
組み合わせてデータ構造を作れるような言語にするのか？」ってトコロから
考える必要があるかと。

単に $foo, @foo, %foo, $$foo ぐらいで済む程度の文法なら 670 の案や
1トークン方式で良し。Perl5 フルコンパチにしたければ変数関係だけで
{}, [] ののネストが発生するので、ネストは正規言語では処理できない
ことを考えると、ある程度は構文解析に逃がした方が楽そう。

674:デフォルトの名無しさん
05/07/10 21:13:41
いずれにせよ、スレ違い
Li(ry)

675:デフォルトの名無しさん
05/07/10 21:17:02
LISPなら字句解析も構文解析も要らないのに。

676:デフォルトの名無しさん
05/07/10 21:24:23
すまん。素でわかんないんだが、「LISP　は字句解析が要らない」ってのは
　　　　1.0
ってのが出てきたとき、それがシンボルか数値かリストかどうかを判断しなくても良いってことなのか？

あと、「LISP　は構文解析が要らない」ってのは、カッコの対応が取れて無くても気にしないってことなのか？

677:デフォルトの名無しさん
05/07/10 21:27:15
>>675-676　ネタ決定

678:デフォルトの名無しさん
05/07/10 21:56:58
字句解析がいらない
→入力をreadするとS式が出てくる

構文解析がいらない
→S式をevalすると結果が出てくる

679:デフォルトの名無しさん
05/07/10 22:00:33
それは要らないんじゃなくて、組み込みになってるだけじゃないの
自分で一から作るなら、どっちも必要でしょ

680:デフォルトの名無しさん
05/07/10 22:15:01
自分で一から作るつもりならLISP必要ないよ

681:676
05/07/10 22:25:03
なんかよく分かった。そりゃ必要ないよな　LISP　側で全部用意してもらえてるんだし

682:デフォルトの名無しさん
05/07/10 22:32:57
あえてLISPを使う意味は中間形式としてS式で処理できるからじゃないかと
S式に優位性を感じないなら必要ない

683:デフォルトの名無しさん
05/07/10 22:34:15
昔prologスレで見た流れだ。
prologインタプリタをprologで書ける人とCで書ける人ではどちらが優れているか？

684:デフォルトの名無しさん
05/07/10 22:44:38
>>678
つまんねぇネタ。

685:デフォルトの名無しさん
05/07/11 01:56:10
ネタに見えるのか。

686:デフォルトの名無しさん
05/07/11 03:28:22
>>685
お前が言わんと欲する所が、あまりに陳腐過ぎて、
細かい説明するのが面倒つうこと。

687:デフォルトの名無しさん
05/07/11 06:30:49
Lisper は他でやってくれ

688:デフォルトの名無しさん
05/07/11 11:37:21
そのLIPSぐらいしか話題ないってことなんじゃないの。

689:デフォルトの名無しさん
05/07/11 16:37:20
>>688
燃料投下(>>674)までの流れを見た上で言ってるのか？

690:デフォルトの名無しさん
05/07/11 18:35:40
燃料に見えるのか。

691:デフォルトの名無しさん
05/07/11 18:55:26
688はキヤノン社員

692:デフォルトの名無しさん
05/07/11 19:22:03
ここはLisp擦れ

693:デフォルトの名無しさん
05/07/11 19:49:05
内部イテレータのある言語を設計してみたいと思ってるんですが、
Ruby以外に内部イテレータを持ってる言語って何がありますか？
Rubyの内部イテレータではなく、一般に内部イテレータとは
匿名関数と本質的にどの点で違うものなんでしょうか。

694:デフォルトの名無しさん
05/07/11 20:15:01
「Rubyの内部イテレータ」について説明してくれたら答えられるかも。

695:デフォルトの名無しさん
05/07/11 21:29:03
>>693
>Ruby以外に内部イテレータを持ってる言語って何がありますか？
このスレでさんざん出てきてるLISPというやヴぁい言語のインライン関数が元ネタ。
Rubyで内部イテレータとわざわざ限定してるのは対象データの
コンテナを抽象化して取り出すことを目的にしてるからじゃないかと。

>一般に内部イテレータとは匿名関数と本質的にどの点で違うものなんでしょうか。
質問の意図が不明だけど、まず役割が違うでしょ。
内部イテレータに匿名関数（ブロック）を渡してぶん回すんだし。
匿名関数側は取り出す要素の構造以外知らなくていいし、
内部イテレータはぶん回すコンテナの構造以外知らなくていい。
外部イテレータとの違いはここにある。

696:デフォルトの名無しさん
05/07/11 22:43:27
つまり、Ruby>Lisp ってことですか？

697:デフォルトの名無しさん
05/07/11 22:54:58
mapとどう違うんだ？

698:デフォルトの名無しさん
05/07/11 23:07:43
mapが何か関係あるのか？

699:デフォルトの名無しさん
05/07/12 00:25:21
ここはLispとRubyの話は禁止
どうしてもやりたいのなら別スレ立ててそっちでやってください

700:デフォルトの名無しさん
05/07/12 00:25:38
>>693
Smalltalkにはブロックという概念があり、これがちょうどRubyの内部イテレータ（ブロック）に相当します。
Lispのmapとも似ていますが、どちらかというとSmalltalkのほうに似ているんじゃないでしょうか。
Smalltalkとの違いは、Rubyでは基本的にメソッド1つにつき1つのブロックしか渡せませんが、Smalltalkは複数のブロックを渡すことができることです。

なおRubyでは、昔は本当にイテレータとしてのみ使われていましたが、今は他の用途にもよく使われるため、現在ではブロックと呼ばれることが多いようです。
また「内部イテレータ」というのは使われ方の名称であって、機能としては「クロージャ」というのがプログラミング言語一般の用語です。
（「クロージャ」という機能を「内部イテレータ」として使うということ）

701:デフォルトの名無しさん
05/07/12 01:06:35
実装的にはイテレータとしてのみブロックを渡す場合は、
真面目にクロージャを作る場合よりも省略できる部分が、
結構あるんだよね。
あと、内部イテレータと外部イテレータにはそれぞれ、
長所と短所がある。簡便なのは内部イテレータだが、
複雑なイテレーションの場合は外部イテレータのほう
が良い場合もある。
個人的なオススメはクロージャが扱えるオブジェクト
指向言語なら外部イテレータを基本に設計して、内部
イテレータはライブラリで用意する、というやり方。

702:デフォルトの名無しさん
05/07/12 02:56:11
>実装的にはイテレータとしてのみブロックを渡す場合は、
>真面目にクロージャを作る場合よりも省略できる部分が、
>結構あるんだよね。

詳細きぼんぬ

703:デフォルトの名無しさん
05/07/12 03:01:01
>>702
環境をスタックからヒープに移すタイミングの問題。

704:デフォルトの名無しさん
05/07/12 04:07:52
特殊用途向けに制限掛かったクロージャ?

705:デフォルトの名無しさん
05/07/12 07:33:41
>>693
構文に関して言えば、
内部イテレータに特化した構文(だったものも含む)を持ってる言語は
俺の知ってる限りでRubyとSmalltalkだけかな。
他になんかあったっけ？

706:デフォルトの名無しさん
05/07/12 09:26:54
>>705
SmalltalkのCollection関係の
　aCollection do:[each: 一件ごとの処理].
とかは言語組込みの構文じゃなくてクラスライブラリの命名ルールだよ。

707:デフォルトの名無しさん
05/07/12 21:43:33
つまり Ruby が最高言語ということでファイナルアンサ？

708:デフォルトの名無しさん
05/07/12 21:54:55
ここの連中はRubyとLISPの名前を出せばほいほい釣れるよ。

709:デフォルトの名無しさん
05/07/13 08:56:12
あたしのために喧嘩なんてしないでッ

710:デフォルトの名無しさん
05/07/14 20:44:00
　　　　　　　　　　　　　　　　　　　　　　　　 .,Å
　　　　　　　　　　　　　　　　　　　　　 .r-‐i'''''''''''i''''‐-､
　　　　　　　　　　　　　　　　　　　　o|　ｏ!　.ｏ　 i ｏ　!o
　　　　　　　　　　　　　　　　　　　　.|＼__|｀‐´｀‐／|__/|
　　　　　　　　　　　　　　　　　　　　 |_, ─''''''''''''─ ,､ /
　　　　　　　　　　　　　　　　　　　　､-'　　　　　　u　　 -､　
　　　　　　　　　　　　　　　　　　／　U　　　　　　　　　0 ＼
　　　　　　　　　　　　　　　　　/　　　　　　　　　／　　　　　i
　　　　　　　　　　　　　　　　　|　　 ● ,,.　　　.,, ●　　　　　 |　
　　　　　　＿＿　　.　　　　　 !　　　　（_人__）　　　　　　　ﾉ
　　/´￣　　　 `!.　　　　　　丶_ 　　u　　　　　　　　U　ノ
　｜　｀にこ匸'_ﾉ .　　　　　　　'-､､,,,,,,__＿＿__＿,,,,,,､､-'
　ﾉ　u 　{　　　　　　　　　　 _.. -―| :{　　　,/ / 　＼
. /　l 　　｜　＿＿　／￣￣｀>'´　　　ノ' 　　　´　{､　　　＼
/ |/　　　 {'´　　　｀ヽ.　"￣＼ U　｀ヽ.　　 __,,..　-‐丶　u 　ヽ
| /　ヾ､..　 }　　　 u'　〉､　　　}　　　　`ｰ''´　　／´￣｀ヽ '"￣＼
! :}　　)「` ﾉ、　　　　ノ　l＼"´_,,ﾆ=-― <´　ヽ{　ノ（　　　`、　　｜
l　　､_,／ｊ　`ー一''"　　 },　ﾉ ,　 '''''""　＼　ヽ ⌒ヾ　　　 v　 |
ヽ　　　＿　　　　　　　 / 　 } {. { l ┌ｎ‐く　ヽ／　``＼　　　　ﾉ
　｀¨´　　｀¨¨¨¨´￣`{ 0 　｀'^┴'ｰ┘|ヾ　　 }、　u' 　 `　 --‐r'′ ｷﾝｸﾞﾔｯﾀｽ！！

711:デフォルトの名無しさん
05/07/14 22:08:03
>>709
リンゴタン？

712:デフォルトの名無しさん
05/07/15 22:18:25

LALR age

713:デフォルトの名無しさん
05/07/16 18:07:28
現在確認されている厨

・RUBY厨
・LISP厨
・りんご厨
・LALR厨

714:デフォルトの名無しさん
05/07/16 18:13:11
上から３番目のは、昔かたぎのFlash職人(元Macromedia Director職人)か？

715:デフォルトの名無しさん
05/07/16 18:22:18
>>713
LALRもダメでつか

716:デフォルトの名無しさん
05/07/16 19:13:12
りんごってVIPのことだろ

717:デフォルトの名無しさん
05/07/16 21:10:41
ここで暴れてる荒らしは、荒らしな上にアンチLISPにアンチRubyに
アンチLALRか。
救いようがねぇなｗ

718:デフォルトの名無しさん
05/07/16 21:13:59
志村坂上

719:デフォルトの名無しさん
05/07/18 15:40:14
すいません超初心者なんで的外れなことを覚悟で質問します。

bison/flexではいたコードってVCでコンパイルできますか？？

720:デフォルトの名無しさん
05/07/18 15:50:45
>>719
やってみればいいじゃん

721:デフォルトの名無しさん
05/07/18 16:57:29
ってゆーかRUBY最強

722:デフォルトの名無しさん
05/07/18 17:30:55
>>708

723:659
05/07/22 02:50:23
>>719

>>657-659 読め。

bison/flexで吐いたコードをVC++でコンパイルした経験は、俺はある。

724:723
05/07/23 23:01:08
>>723
ありがとうございます。よく読んでいませんでした。

とりあえず原田賢一著　コンパイラ構成法という本を購入しました。
これから勉強します。

725:719
05/07/23 23:01:49
すいません719です

726:デフォルトの名無しさん
05/07/25 02:13:48
LexやYACC等のツールを使わないとコンパイラ作れない奴なんざ
雑魚だろマジで。

727:デフォルトの名無しさん
05/07/25 02:15:53
>>726
字句解析とか構文解析とか、単純なんだから別に自動生成でいいやん。
ていうか、こういうツールだって、どういうことやってるのか理解できない人には使えないと思うよ。

728:デフォルトの名無しさん
05/07/25 14:06:30
>>726
rubyの作者を雑魚あつかいですか？

729:デフォルトの名無しさん
05/07/25 15:05:00
>>726のようなことを言う奴はコンパイラのバックエンドをろくに書けない奴に多い。
たぶんフロントエンドだけがやっとで挫折したんだろう。

730:デフォルトの名無しさん
05/07/26 10:08:34
LexやYACC等のツールを使わないとコンパイラ作れない奴が雑魚なら、
LexやYACC等のツールを使わずにコンパイラを作る奴はフジツボ。
LexやYACC等のツールを使えない奴はプランクトン。

731:デフォルトの名無しさん
05/07/26 12:20:11
ここは酸っぱい葡萄が多いインターネットですね。

732:デフォルトの名無しさん
05/07/26 20:48:40
イソップ童話ｷﾀ━━━(ﾟ∀ﾟ)━━━ !!!!

733:デフォルトの名無しさん
05/07/26 21:15:44
言語鍛冶が覆面で議論するスレはここですか？

734:デフォルトの名無しさん
05/07/29 11:04:33
JavaScriptのコンパイラコンパイラが欲しいんだけれど、調べた限りではないみたいなので、
これを機会に時間のあるときに作ってみようと思ったのだけれど、
コンパイラコンパイラ実装の参考文献で良書はありますか？英文和文問いません。

735:デフォルトの名無しさん
05/07/29 22:56:38
ネタとしてスルー。

736:デフォルトの名無しさん
05/07/30 01:54:03
JavaScriptでかかれたコンパイラコンパイラ？(まさか～）

でも文脈からだとJavaScriptの構文を理解するbisonコードくさいんだけどさ。

737:デフォルトの名無しさん
05/07/30 02:03:01
コンパイラコンパイラが生成するコードがJavaScriptのものなんじゃないの？

738:デフォルトの名無しさん
05/07/30 02:04:06
Mozillaのソースとか・・・・・・・・

739:734
05/07/30 02:13:44
>>737
そう、そういう意味です。
JavaScriptで出来たコンパイラコンパイラなんてあれば面白いけれど…

740:デフォルトの名無しさん
05/07/30 06:12:34
>>734 >>734

741:デフォルトの名無しさん
05/07/30 06:52:32
ドライバだけJavaScriptなら簡単なんじゃん?

742:デフォルトの名無しさん
05/07/30 07:54:28
CからJavaScriptに変換するトランスレーター作れよ

743:デフォルトの名無しさん
05/07/30 17:52:12
>>734
LALRパーサージェネレータでよければ、kmyaccでサポートしてます。
URLﾘﾝｸ(www005.upp.so-net.ne.jp)

こうした方がいいという意見も歓迎。

JavaScriptで書いたデモの例
URLﾘﾝｸ(www005.upp.so-net.ne.jp)

744:734
05/07/30 19:50:44
>>742
それは良いアイデアですね。
JavaScriptの言語的機能は制限されるのが残念ですが、
とにかく使いたいだけならそれは良さそうです。

>>743
おお、これはそのまま使えますね！ありがとうございます。
早速使ってみます。助かりました。

745:デフォルトの名無しさん
05/07/30 21:10:39
>>744
使うにあたってはプロトタイプを手直しした方がいいでしょうね。

ところで、JavaScriptでは入力を得る手段が限られていると思うのですが、
どんな対象をパースするのか、さしつかえなければ教えてもらえませんか？

746:734
05/07/30 23:40:21
>>745
助言ありがとうございます。
JavaScript ObfuscatorをJavaScriptで書こうかと思っていました。

747:デフォルトの名無しさん
05/07/30 23:57:26
>>746
ようするにスクリプトを読まれたく無いと。
ただそれだけ？

748:734
05/07/31 00:11:31
>>747
そういうわけじゃないですよ。どちらかといえば趣味です。

その時は手動で構文解析を作りましたけれど、
チェスの掲示板に棋譜を読み込むためにPGNファイルのフォーマットをパースするなど、
JavaScriptでコンパイラコンパイラが作れればいいなーと思うことは稀にありました。

749:デフォルトの名無しさん
05/08/03 12:01:25
ちょっと趣旨が変わってしまいますが…
状態遷移を扱うのに適するエンジンってありませんか？

やりたいことは、入力を受け付けて、新しい状態を出力するモジュールです。
その状態遷移ルールは何らかの自作エディタでペトリネットやUMLの
アクティビティ図のように記述しておきます。

単にゴリ押しで、定義データに各遷移ルールを記述しておき、制御モジュールで
パターンマッチングで次の状態を探すだけでも可能ですが、トークンのJoinとか
考えると、いろいろ内部情報を保持する必要があります。

普通のスクリプトやゲームのシナリオなんか参考になる気もしますが、今回の場合、
有限状態機械に特化したもので十分です。
また、状態遷移図の定義の変更は頻繁に行われます。

もし、美しいアーキテクチャがあるなら、ゴリ押しのエンジンを作り直したいと
思っているのですが、オブジェクト指向で機械の内部状態とか定義方式を美しく
表現している設計って、どこかにないでしょうか？

750:デフォルトの名無しさん
05/08/03 13:04:20
>>749
＞オブジェクト指向で
限定しない方が良いよ。OO　に限定するとステートパターンしか出てこないから

751:デフォルトの名無しさん
05/08/03 13:10:40
状態遷移を美しく表現する設計は興味があるな。
世の中ではどんな形なんだろう

752:デフォルトの名無しさん
05/08/03 21:01:28
オブジェクト１つが、１つの有限状態機械だと思ってる。
UMLでもステートチャート図あるし
状態遷移をオブジェクト指向で表そうとするのは適切でないような気がするけど

753:デフォルトの名無しさん
05/08/03 22:18:27
う～ん、でも、オブジェクトを入出力とするエンジンって有り得ないですかねぇ。
事前の状態遷移定義に従って、オブジェクトAがエンジンによってBに変えられるような。

別にオブジェクト指向に拘る訳じゃないですが、オブジェクト指向を例にとると、
1つのオブジェクトが、エンジンに渡されると、2つのオブジェクトに分岐したり、
その逆に2つのオブジェクトが揃ったら、1つのオブジェクトに合流したり…
さらに、その合流待ちの状態が無限って訳にはいかないだろうから、生存時間が決まってたり。

こういうのって、昔から学術的には扱われてると思うのですが、
実際に実装するとなると、どういう定義記述方法にして、どんな内部状態を持たせるのかなぁと。
もしかして、何か美しい設計が、すでにあるのかと思った次第です。

今なら、定義はXMLになるのかなぁ…

754:デフォルトの名無しさん
05/08/03 22:40:13
>>753
まさか…oさん？

755:デフォルトの名無しさん
05/08/04 00:07:42
CodeProject に XML を利用したステート・マシンのサンプルがあったような気が・・・
気のせいだったかも

756:デフォルトの名無しさん
05/08/04 05:06:54
要求に合うかどうか判らないけど、
Object指向でPush-down automatonならFinate State Machine。
尚、定義ファイルのパースは別途必要です。

757:デフォルトの名無しさん
05/08/04 16:54:55
>>754　いいえ違います。

>>755
URLﾘﾝｸ(www.codeproject.com)
キャ━━(*´∀｀*)━━ !!!!!
と思いましたが、よく見ると、これ、現状のコードとスタート地点同じ気がします…
この先、アクティビティ図とか、ペトリネットレベルまで拡張していくと、
ごちゃごちゃしてきて、もっと美しい設計無いのかと思った次第です。
だから、この先にある、汎用性のあるものが知りたいと…
我侭で申し訳ありません。

>>756
有限状態オートマトンの汎用エンジンに、興味あります。
Radiumさんの過去ログに記述ありました。月末の2日分です。
URLﾘﾝｸ(www.radiumsoftware.com)

このEventStudioというものが、なんか実現してるっぽいです。
URLﾘﾝｸ(www.eventhelix.com)
少し詳しく読んでみたいと思います。

758:デフォルトの名無しさん
05/08/05 23:48:44
boost::fsm...

759:デフォルトの名無しさん
05/08/06 22:01:29
>>750
StatePatternで何か不都合があるのか？

760:デフォルトの名無しさん
05/08/07 00:27:31
URLﾘﾝｸ(www.eventhelix.com)

これは、どの辺がいいの？解説求む。

761:デフォルトの名無しさん
05/08/17 09:13:09
Windows上で、JITで生成したnative codeを、
DLL形式でファイルに保存して実行するのではなくて、
メモリに保存して実行する方法を教えてください。

762:デフォルトの名無しさん
05/08/18 02:30:07
誰かC++の関数スタックを活かしながらSchemeの継続を実装する方法を教えてください。
……できそうにないのはわかっているけど、あきらめるのはちょっとくやしい……

763:デフォルトの名無しさん
05/08/18 03:50:57
>>762
大域脱出のみに使われるような継続であることがSchemeのプログラム
を解析して証明できる場合なら、setjmp/longjmpでいけるんじゃね？
Schemeコンパイラ関連の文献読むと、色々ヒントが書いてあるよ。

764:デフォルトの名無しさん
05/08/19 00:42:56
やっぱり脱出方向だけにしてsetjmp/longjmpぐらいしかないか……

真面目に継続使いたかったら(自前でstack作ったりして)継続を管理するしかないのかな。
……Commandパターン使って少しでも手を抜くとするか……

765:デフォルトの名無しさん
05/08/19 03:04:24
>>764
SchemeをCPSでCにコンパイルする方式。
URLﾘﾝｸ(home.pipeline.com)

C関数はreturnしないので、スタックはヒープとして使う。
いっぱいになったらcopying GC。

766:デフォルトの名無しさん
05/08/19 23:28:22
自作言語に正規表現libをなんとかして融合しようと思ってるんだけど
リテラルとして組み込むと内部で正規表現objectと文字列リテラルの切り分け
みたいなのが別途必要っぽいし、ライブラリとして組み込むと呼び出し手順が
複雑になって結局使われないんじゃないかとか色々考えても良さげな方法が
みつからなかった。

つーかrubyみたくperlの真似して/～/にすると//という１行コメントと勘違いする
かもしんないし、/はそもそも割り算に使ってるし。
独創的な構文にしすぎてメンテする俺自身忘却するようなの作っても
それはそれで意味ないし別に/～/でもいいけどよ、出現位置によってトークンの
意味が変わるのって言語として変な気がするんだけどおまえらどうですか？

767:デフォルトの名無しさん
05/08/19 23:53:09
馬鹿の考え休むに似たり

768:デフォルトの名無しさん
05/08/19 23:54:27
正規表現を捨てて、MLのようなパターンマッチ構文導入がトレンド（大嘘）

769:デフォルトの名無しさん
05/08/20 01:38:30
>>766
個人的には Perl6 のパターンマッチングが好きだ。

770:デフォルトの名無しさん
05/08/20 01:57:23
コメントが//なら
|～|にする。

771:デフォルトの名無しさん
05/08/20 07:53:05
とりあえずm4みたいにリテラルの前後変更できるようにしてさっさと組んじゃえば。

772:デフォルトの名無しさん
05/08/20 09:12:02
>>766
独自の記号から作ってもいいんじゃない？
「この言語で開発するときのフォント」って感じで
フォントと文字コードの定義から言語にしちゃうの。

そうすれば、紛らわしい記号に悩むことないし、
今まで２文字使っていた演算子も１文字ですむし
区別もはっきりするし、いいことずくめ

昔と違ってＰＣの性能はあまるぐらいなんだし
フォントぐらい共有しない独自のだって大丈夫だよ

773:デフォルトの名無しさん
05/08/20 12:57:10
orz～orz
にしようよ

774:デフォルトの名無しさん
05/08/20 13:07:40
>>772
APLって知ってる？
独自記号の演算子だらけの言語。
MLやBBSなんかにコードをコピペできないとかいろいろ不便すぎて、
結局普通の文字コードの範囲で表現するほうがいいというのが結論。

例えばこのスレにもコードを貼れないよ。

775:デフォルトの名無しさん
05/08/20 15:41:01
>>774
そっか、そういうのがあるのかぁ。

でもその結論が出た時点とも今は違うんじゃない？
あ、Unicodeのワイド文字なら使ってもよさそう。

HTMLのエンコードみたいに＆lt；とかで内部表現しとくとか。

776:デフォルトの名無しさん
05/08/20 15:51:47
1. ワイド文字を持ったフォントを使ってるとは限らん
2. コペ時に表現が変わったら読みづらくてかなわん。
　昔のSmalltalk(Squeakは今でも)はフォントがいじくられてて、
　代入記号に←を使っていたが、コペると_になってダサダサだった。

777:デフォルトの名無しさん
05/08/20 16:15:04
日本人なら積極的に漢字を使おうぜ。
『置換「　」を「　」に。』
これでどうだ！
なんかひまわりの二番煎じっぽい気もする。

関係ないけど、'コペる'って斬新だな。
どこか間の抜けた響きで気に入った。

778:デフォルトの名無しさん
05/08/20 16:31:39
コペる21

779:デフォルトの名無しさん
05/08/20 20:11:25
最近、変数名、関数名、クラス名とかに漢字遣ったほうがわかりやすい気がしてきた。

780:デフォルトの名無しさん
05/08/20 20:26:16
補完やってくれるなら。
IMEのネックがあるかぎり漢字は受け付けないなあ。
名前考えるの面倒とは思うけど。

781:デフォルトの名無しさん
05/08/21 00:09:23
>>766
使うひとのことを考えて、できればリテラルで。
JavaやPHPのようにライブラリとしてしまうと、正規表現を文字列で指定しなきゃならん。
そうなるとエスケープがすごく面倒で、使う人にとってよくない。
リテラルとして言語仕様に組み込めば、おまえがしんどいだけで、使う人はハッピー。

構文はPerlやRubyをまねしたほうがよい。
使ってもらうことを考えたら、よほどの利点がない限りは他の言語と同じにしたほうが、使う人にとって敷居が低い。
おまえの独自言語のウリは正規表現にあるわけじゃないだろ、きっと。
ウリになる部分は独創的にしてかまわんが、ウリにならない部分はオーソドックスにしとけ。

コンテキストによって記号の意味が変わるのは、確かに悩ましいところだが、お前が苦労すればいいだけのこと。
使う人に苦労をさせるな。勉強しろ。
それでも「昔の仕様をひきづって変なコードになるのはイクナイ！」と思うなら、そうだな、「@/rexp/」とか「./rexp/」にでもしとけ。
まあRubyはPerlをまねただけで、Perlはsedをまねただけで、sedはviやedをまねただけで、edは割り算記号なんかなかったから問題なかっただけなんだけどな。よく考えたらそんな昔の仕様を今でもひきずるのはおかしい気がしてきた。

782:デフォルトの名無しさん
05/08/21 00:18:13
>>781
同意。
例えば正規表現リテラルが #/rexp/ の言語処理系も実際あるわけだし。
このくらいだと違和感なく使える。

783:デフォルトの名無しさん
05/08/21 12:05:31
スラッシュの代わりに別の文字を使えるようにするのも忘れるなよ～
これ便利だから

784:デフォルトの名無しさん
05/08/21 23:38:39
主な括弧の場合は対応する閉じ括弧で終われるようにね

785:デフォルトの名無しさん
05/08/21 23:44:59
>>765
これを実装したSchemeコンパイラは公開されてるんでしょうか?

786:デフォルトの名無しさん
05/08/22 01:43:41
>>766
プリプロセッサで関数呼び出しに置き換えちゃうとか

787:デフォルトの名無しさん
05/08/22 02:52:36
プリプロセッサだと実際の行番号がわからんという不具合を抱えることになる
まあやり方次第かもしれないけど

788:デフォルトの名無しさん
05/08/25 03:42:41
>>785
Baker本人はもちろん実装してるんでしょ。
ほかにこんなのもあるようです。
Chiken Scheme Compiler
URLﾘﾝｸ(www.call-with-current-continuation.org)

しかしすごいドメイン名。

789:デフォルトの名無しさん
05/08/25 12:04:31
あるかどうかじゃなくて公開されているかどうかでは？

790:デフォルトの名無しさん
05/08/25 23:53:57
>>789
リンク先見てから言ってくれ。

791:デフォルトの名無しさん
05/08/26 01:39:26
リンク先を見ろという前にchikenが785の質問に合致するかどうかを説明すべきでは?

792:デフォルトの名無しさん
05/08/26 05:00:15
この話の流れで実は合致しないというオチだったらびっくりだな。

793:デフォルトの名無しさん
05/08/26 08:19:29
>>791
いたれりつくせりを要求してんな

794:デフォルトの名無しさん
05/08/31 22:12:59
おまいら日経ソフトウェアがきましたよ
URLﾘﾝｸ(software.nikkeibp.co.jp)

795:デフォルトの名無しさん
05/08/31 22:38:04
>Part4　Javaで作るオリジナル言語
>　　～やさしいLispインタプリタの作り方

オワタw

796:デフォルトの名無しさん
05/08/31 22:50:42
JavaでLISPなんて泥臭い部分全部端折ってるじゃん

797:デフォルトの名無しさん
05/09/01 00:02:08
testや最適化という一番泥臭い部分が残ってます。

798:デフォルトの名無しさん
05/09/01 01:26:34
test？はよくわからんが、最適化なんて枝葉だからどうでもいい

799:デフォルトの名無しさん
05/09/01 01:35:23
>>798
世の中のコンパイラ屋さんが泣いています

800:デフォルトの名無しさん
05/09/01 12:22:04
lispでtestって無茶簡単なような

801:デフォルトの名無しさん
05/09/01 16:18:08
>>799
いや、雑誌の件はインタプリタだから（ｗ
正直java製のLISPインタプリタでタイトルに「簡単」とか書いてあると、
読まずに中身が解ってしまう気がするのは俺だけじゃないと思う。
バイトコードにコンパイルするとかならもの凄くおもしろそうなのに。

802:デフォルトの名無しさん
05/09/02 08:14:28
>>801
コンパイルは雑誌記事ではちと荷が重くないかい？
特集で3回くらい組まないと、紙面ではあるていどちゃんと説明できないだろうし。

803:801
05/09/02 14:23:52
>>802
確かに、雑誌では重いのは大変よくわかります、はい802氏の言うとおりです。
でもLISP（Schmeの方がより良いと思いますが）のネイティブ（バイトコード含む）へのコンパイルと最適化って
書籍では見かけた事が無いのですよ（国内しか調べてません、英語文献があれば教えてくれると嬉しい）
で、結局皆どこを見に行くかと言うとACMとか、各大学の論文とかなんですよ。
情報工学出じゃないと検索すら泣ける結果が多いから、日本語で書籍で出せば結構なインパクトあると思うのですがね。

中田先生の書籍は関数型言語より手続き型言語の物だけだしorz

804:802
05/09/02 17:25:05
>>801
コンパイラについて体系立った形で書籍として提供されれば、漏れも買うな。
しかし、話の流れは雑誌だし。
Lispのコンパイラについては、昔々にKCL(古っ）のソース読んだりして独学したけど、
あれは出力がCだし。

最近の処理系では、
URLﾘﾝｸ(dmoz.org)
なかんじなのだろうか。いくつかコンパイラもあるようだから、ソース読んでみるかね。

805:デフォルトの名無しさん
05/09/03 14:23:24
>>803を読む限り、Lispに特化した最適化や高度な最適化というより、
関数型言語のコンパイルと最適化の基本を知りたがってるように感じた。
もしそうならLispに限ることないんじゃないかな。
多分mincamlとか見るといいと思う。
URLﾘﾝｸ(min-caml.sourceforge.net)

806:デフォルトの名無しさん
05/09/03 15:57:02
>>805
そこでAppel先生ですよ

807:デフォルトの名無しさん
05/09/03 23:50:18
オイオイ、好い加減LISPの話はよせ。
おまえらつられすぎw

リンゴタソ、ハァハァ

808:デフォルトの名無しさん
05/09/03 23:53:42
>オイオイ、好い加減LISPの話はよせ。
なんで？
きみが嫌いなだけか？
理由でも書いてくれると話が広がるんだが。

809:デフォルトの名無しさん
05/09/04 00:41:31
もともとは日経プログラミングの記事の話題なんだっけ

810:デフォルトの名無しさん
05/09/04 01:01:50
質問です。
デザインパターンのInterpreterパターンはLL(1)文法しか
記述出来ないのでしょうか？
LALR(1)文法をInterpreterパターンで実装することは可能でしょうか？

811:デフォルトの名無しさん
05/09/04 13:20:17
>>808
だから807は広げたくないんだろｗ

812:デフォルトの名無しさん
05/09/04 18:47:46
807=811
コテハン名乗ってくれ
透明化するから

813:デフォルトの名無しさん
05/09/04 19:11:24
つNG word: w

814:デフォルトの名無しさん
05/09/04 19:41:39
ついでに、LALRも金句らすい

815:デフォルトの名無しさん
05/09/04 19:52:42
>>810
可能だよ。
Interpreter パターンの LL(1) 解析部を LALR(1) に改造すれば良い。
再帰下降方にする事だって出来る。

しかも Interpreter パターンであることに変わりは無い。

816:デフォルトの名無しさん
05/09/04 21:25:29
Interpreter パターンと Visitor パターンを混ぜて
どうこうするのって妙にわかりにくいというかしっくりこないと
いうか
オブジェクト指向の中に無理やり詰め込んでるような気がするのは
俺だけだろうか？？

817:デフォルトの名無しさん
05/09/04 21:29:56
つ[ｽﾚﾘﾝｸ(tech板)l50]

……っていうかお前マルチやんか

818:デフォルトの名無しさん
05/09/04 21:56:59
つりんごタソ

819:デフォルトの名無しさん
05/09/04 22:08:26
>>815
ありがとうございます。
まずはLL(1)で簡単なものを作ってみて
その後LALRに変えていこうかと思います。

820:デフォルトの名無しさん
05/09/08 20:45:28
アフォ？
なんで、llからlalrにかえんのw

821:デフォルトの名無しさん
05/09/08 20:58:17
出来ないことを出来るようにするため

822:デフォルトの名無しさん
05/09/09 01:41:01
>>820
馬鹿かお前？

823:デフォルトの名無しさん
05/09/09 05:41:33
理由を書かないお前が馬鹿なのは明白ですｗ

824:デフォルトの名無しさん
05/09/09 11:24:47
本人じゃないから本当のところはわかんないけど、
LLでは扱えない構文を導入するのかもしれないし、
単に勉強のためなのかもしれない。
そんなことも思いつかずにアフォ呼ばわりするお前の成績は不可。

825:デフォルトの名無しさん
05/09/09 12:51:03
要するに、何も特定できないのに横からしゃしゃり出てきて
煽ってるだけってことですね。みっともないｗ

826:デフォルトの名無しさん
05/09/10 00:27:02
つーか普通にLLだと左再帰の問題があるだろ？

827:デフォルトの名無しさん
05/09/10 00:34:45
粘着にレスするのいいかげんやめようよ……

828:デフォルトの名無しさん
05/09/10 08:59:05
そうだな。以降>>827は放置で。

829:デフォルトの名無しさん
05/09/10 09:35:36
C++の名前空間ぽくしようと思ったけど
面倒くさすぎてやめた
やぱモジュール形式かな

830:名無しさん＠そうだ選挙に行こう
05/09/10 20:27:29
>>829
ひとりごとは、他でやってくれ。

831:名無しさん＠そうだ選挙に行こう
05/09/10 21:14:14
敵幹部「名前空間にひきずりこめ～」
宇宙刑事「うわ～」

832:名無しさん＠そうだ選挙に行こう
05/09/10 22:24:33
>>831
何その間抜け時空

833:名無しさん＠そうだ選挙に行こう
05/09/11 01:05:32
よーしスーパーササニシキだ

834:デフォルトの名無しさん
05/09/12 00:11:02
質問です。文法がLR(1)かどうかというのを、状態遷移図を完全に書かずに判断できますか？
たとえば、

S→V$
V→(L) | x
L→V | V;L

という文法があった場合、直感的にはLR(1)文法であると思われますが、理由が説明できません。
証明のためにLR(1)項集合の状態遷移を全部書くと結構な量になりそうです。
すべての状態遷移を書かずに証明する方法は無いものでしょうか。

次ページ