06/12/10 12:30:47
ちょっとスレ違いかもしれないけど質問です。
今、プロトタイプベース（移譲中心）の俺言語を作っているんですけど、
ダイアモンド継承の処理の方法に悩んでいます。
ダイアモンド継承についての良さげな文献とかありません？
233:デフォルトの名無しさん
06/12/10 16:06:21
>>232
C++のD&Eを見れば、なんか参考になることが書いてあるかも。
234:232
06/12/10 17:05:23
>233
見ました。良い本だよね。D&E
「vtblを間接参照する」までは載ってたけど、流石に同一仮想ベースクラスを
効率的に検索する実装までは載っていませんでした。
プロトタイプだと、下手すると変数を参照するたんびに移譲先を探さなきゃ
いけないので、このあたりの処理は悩ましいですよね……
235:デフォルトの名無しさん
06/12/10 17:28:08
>>234
じゃ、そこらのC++コンパイラでvtblをどのように扱ってるか解析するのが近道かもね。
以前、ダイアモンド継承してるオブジェクトのデータ構造を調べたらなんかへんちくりんな構造してたけど。
236:デフォルトの名無しさん
06/12/10 21:35:14
プロトタイプベースでダイアモンド継承というのが理解できない。
プロトタイプベースってことは分裂+突然変異でオブジェクトができるんじゃないの?
237:デフォルトの名無しさん
06/12/10 22:02:46
二つをくっつければいいんだよ
238:デフォルトの名無しさん
06/12/10 22:59:47
>>232
うーむ。日本語でSECDマシンのいい解説があるといいのだけどなぁ。
ほかの英語の論文をちまちま訳しながら、勉強してるところです。
239:デフォルトの名無しさん
06/12/11 01:08:16
>236
ダイアモンド継承と言ったのはちょっとまずかったかな？
実際にはちょっと違います。
俺言語では、こんな感じで
A <= B
a| a|
α<= β
参照aを持つオブジェクトAに委譲するオブジェクトBがある時、
Bからaを参照する場合は、参照先αをそのまま使わずに、αに委譲した
プロキシβを作成してそれを参照するようにしています。
で、何が問題かというと、Aに同じオブジェクトを参照する参照が2つある場合、
A <=== B
a|b a| |b
α<= β |
<=== β'
こんな感じでBの参照aと参照bが別のプロキシになってしまいます。
C++のダイアモンド継承の問題もこんな感じだよね？
240:デフォルトの名無しさん
06/12/12 01:56:15
SECDてこれ？
URLﾘﾝｸ(en.wikipedia.org)
面白そうですな。ちょっと読んでみるよ。
241:デフォルトの名無しさん
06/12/12 20:19:43
CodeZine：JavaScriptでつくるSchemeインタプリタの基礎の基礎（lisp）
URLﾘﾝｸ(codezine.jp)
JavaScriptでLispｗｗｗｗｗｗｗｗｗ
242:デフォルトの名無しさん
06/12/12 22:28:17
>説明の簡略化のため、マクロ、末尾再帰の最適化、継続などの実装は省きます。
それSchemeじゃねぇwwwwwwwww
普通にLispて言やいいじゃん
243:デフォルトの名無しさん
06/12/12 23:37:30
JavaScriptってほとんどschemeやん
244:デフォルトの名無しさん
06/12/13 10:17:13
(ﾟДﾟ )ﾊｧ?
245:デフォルトの名無しさん
06/12/13 23:55:42
scheme with C's clothing?
246:230
06/12/14 18:33:54
>>240
遅レスですが、それです。
HendersonのSECDマシンの実装は出来てるっぽいのだけど、
DUMとRAPの使い方がわかってるような、わかってないような。
JavaScriptだと、
function plus(a){ return a + 1; }(10);
が
(LDC (10) LDF (LD (1 . 1) LDC 1 SUB RTN) AP STOP)
となる。と言った感じの、まともに動くサンプルをつくりたいんだけど。
247:デフォルトの名無しさん
06/12/15 02:33:39
>>246
どうしてそこでSECDの本来のターゲットであるSchemeで考えないのか
とっても不思議なんだけど。
DUMとRAPの用途は、letrec。
そこまで自分のわかってないことがわかったなら、あとは
LispMeのソースを眺めてどういう風に使われるか見れば一発でしょ。
コンパイラとかSECDのコアとかなら、Palm依存のコードを除いて
手元のPCで実行できるようにするのもさして難しくはない。
動かさなきゃ理解できないようなものでもないが。
248:230
06/12/15 15:14:25
SECDマニアのHendersonのプログラムをコンパイルして弄ってみたのだけど
((letrec a (a lambda (b) b)) 1)
が
(LDC (1) DUM LDC NIL LDF (LD (0.0) RTN) CONS LDF (LD (0.0) RTN) RAP AP STOP)
ということでいいのかしら？とりあえず、思ったとおりに動いているのだけど。
letrec用途であることはわかるのだけど、自分で作って動かすとなると動かなくて。
249:デフォルトの名無しさん
06/12/15 23:55:06
coins verup
250:デフォルトの名無しさん
06/12/16 17:49:21
coins使ってる人っている？
251:デフォルトの名無しさん
06/12/16 18:08:30
いません
252:デフォルトの名無しさん
06/12/16 18:09:27
今時Javaって・・気が触れたとしか思えん
253:デフォルトの名無しさん
06/12/16 18:31:30
>>252
あなたなら、今なら何が、コンパイラを作るのにいいと思いますか？
254:デフォルトの名無しさん
06/12/16 19:18:43
Ruby か Haskell だろ
255:デフォルトの名無しさん
06/12/16 19:26:02
そーか? HaskellはともかくRubyは……
作り始めはいいかも知らんが、だんだんチェックが欲しくなってくるから
型がルーズな言語はしんどいよ。
256:デフォルトの名無しさん
06/12/16 20:12:38
C++
boostあれば色んなことできるようになるし。
257:デフォルトの名無しさん
06/12/16 20:16:35
URLﾘﾝｸ(hp.vector.co.jp)
258:デフォルトの名無しさん
06/12/16 20:21:25
>>256
お前は４年前の俺か
259:デフォルトの名無しさん
06/12/16 20:30:50
4年の間にどんなカルト宗教に洗脳されちゃったんだろう
260:デフォルトの名無しさん
06/12/17 02:04:03
適当になれた言語で一応動くものを作ったあと、自己記述化
261:デフォルトの名無しさん
06/12/17 03:09:43
しかし、処理系作るなんておまいらすごいですね。
自分も何れは、自分で設計したスクリプト言語のインタプリターでも作りたいと思ってるんだけど。
ところで、知ってる言語が、C/C++, VB, PHP, Ruby, BASIC なんだけど
インタプリター実装に使う言語としては、この中だとどう考えても、C/C++ になるよね？
あと、こういうのって、ある程度汎用的に使える様な構文解析エンジンみたいなのはフリーで良いのが公開されてる？
それとも、Boostとかの正規表現ライブラリとか使って、自分で解析エンジンとかも製作するの？
262:デフォルトの名無しさん
06/12/17 03:20:04
bison, flex
263:デフォルトの名無しさん
06/12/17 03:43:51
ほほうー これでparserクラスとか作るわけかー
いつか作ろう。
264:デフォルトの名無しさん
06/12/17 18:33:51
いまからbison+flexを覚えるくらいなら最初からantlrに取り組んだ方がいいと思う。
いろんな言語向けのコード生成できるし。
265:デフォルトの名無しさん
06/12/18 23:13:40
C++でお勧めありますか？ 今はspiritでシコシコやってます。
まあ、Forthチックだから大したの要らないんだけど。
266:デフォルトの名無しさん
06/12/19 00:46:02
>>265
spiritを使う気になる環境ｳﾗﾔﾏｼｽ
267:デフォルトの名無しさん
06/12/19 02:03:08
>>265
antlrじゃダメなの？処理系自体もC++で書いてあることが要件なのかな。
大袈裟なのが必要ないならcaperでいいんじゃない？
268:デフォルトの名無しさん
06/12/19 23:22:57
>>250
ソース拾ってきて、眺めて終了してしまってます。。。
もっと、面白い記事がネット上にあればなぁ、思います。
269:デフォルトの名無しさん
06/12/19 23:39:56
>>265
時間の無駄だからやめたほうがいいよ
270:デフォルトの名無しさん
06/12/20 02:02:13
>>265
FORTHチックじゃ構文が分かち書きで切った部分が直接命令に還元されるって事かい？
なら構文解析コード使う事自体に意味がないだろう？
むしろできあがったコードの中身をJITでネイティブに落とすとかそっちの話の方がメインじゃないのかい？
271:デフォルトの名無しさん
06/12/26 20:30:48
来月のPOPLってどうよ？
272:デフォルトの名無しさん
06/12/27 09:30:59
GCCってもっと速くならないの？
273:デフォルトの名無しさん
06/12/27 11:22:09
GCCの何を速くしてほしいの？
274:デフォルトの名無しさん
06/12/27 18:43:19
coinsは遅くなったらしい。
275:デフォルトの名無しさん
06/12/28 04:22:39
中田先生がファビョってるようにしか見えない
もっと落ち着いてメールして欲しい
公の場なんだから
276:デフォルトの名無しさん
06/12/28 15:44:19
たしかにメールの勢いはひどいが
INFOがうざいのも事実。
277:デフォルトの名無しさん
07/01/04 07:30:40
あけおめ
278:デフォルトの名無しさん
07/01/04 11:43:19
COINSのMLどうなった？
スレッドがぐちゃぐちゃで読む気がしないんだけど
279:デフォルトの名無しさん
07/01/06 18:56:49
COINSのMLってどうやったら読めるのですか？
280:デフォルトの名無しさん
07/01/08 11:09:30
COINS使いたいのですが、ヘッダのGCC拡張エラーになります
ヘッダを入れかえるのは、パッケージ管理しているのでやりたくありません
どう対処するのが一般的ですか？
# FreeBSDでは問題無く動いてます
281:デフォルトの名無しさん
07/01/08 11:42:48
超能力者募集中か？>>280
282:デフォルトの名無しさん
07/01/08 11:51:12
>>281
お前には想像力が無いことだけは解った。
283:デフォルトの名無しさん
07/01/08 12:34:19
想像力で補ってどうするよ。いくつ可能性があると思っているんだよ。
まずは >280 が 『回答者が回答するために必要な情報はなんだろう？』 と想像しろ。
自分の環境を特定しようとしないやつに質問する資格は無いわ。
284:デフォルトの名無しさん
07/01/08 12:36:15
>>283
過剰反応。
子供か、君は。
285:283
07/01/08 12:43:16
>284
お前は誰だよ。ちゃんと名乗れ。
これだからIDの無い板は……。技術系の板でID無しって腐ってるよな。
ただ正論言っているだけだよ。 現実世界と違って >280 に気を使う必要無いしな。
早い話、>280は質問の仕方を覚えないと技術系としてはやっていけないよということで。
286:デフォルトの名無しさん
07/01/08 12:50:45
>>285
鬱憤晴らしで初心者いびりがしたいだけだろう？
287:デフォルトの名無しさん
07/01/08 12:51:36
>>286
SOREDA
288:デフォルトの名無しさん
07/01/08 12:52:44
環境もワカラン、どのコンパイラつかってるのかもワカランでどうしろっての？
莫迦？
289:デフォルトの名無しさん
07/01/08 12:59:58
>>288
解らんことがあれば聞け。
ただそれだけだろ。
お前は普段の仕事で、解らんことがあるのでこの仕事はできません、なんて言うつもりか？
290:283
07/01/08 13:21:34
>286
そりゃそうだ。こんなマヌケじゃなぁ……
>288
おまっ、それマジで言ってんの？？？？？
「相手が根気良く確認してくれるのはなぜか？」ということ考えたことある？
確認する側にメリットがあるからじゃないか。
仕事なら『業務を遂行する＝自分の業績に繋がる』というメリットがあるけど
こんな匿名掲示板で根気良く確認しても何のメリットもねぇだろ。
逆に、質問する側は『疑問点を解消する』というメリットがある。
ある意味一方的な関係だ。
だから、こういうところでは回答者に積極的に協力しないとシカトされてお仕舞いなんだよ。
そんなに手取り足取り確認したけりゃCOINSのサポートに頼め。
COINS コンパイラ・インフラストラクチャ協会も無償奉仕みたいだから、>280みたいな
質問の仕方だと、「何いってんの、お前」というのをやんわりと言われるかもしれんがな。
291:デフォルトの名無しさん
07/01/08 13:36:54
仕事のような熱心さで、２８０の質問に答えてくれる人、
募集中というところかｗ
292:デフォルトの名無しさん
07/01/08 14:17:30
libc の header に gcc 拡張が使われていて
coins が gcc 拡張を理解できないからエラーになるんだろ？
いいじゃん glibc なんか捨てて *BSD 使えば
293:デフォルトの名無しさん
07/01/08 14:23:58
むしろsolarsiのでばんですよ
294:デフォルトの名無しさん
07/01/09 01:28:52
>>279
中の人に頼み込む。
295:デフォルトの名無しさん
07/01/09 03:38:44
自分の質問の馬鹿さを指摘されたあと見せる無駄なエネルギーの半分でいいから、
元の質問文の練り込みに使えばいいのにな。
296:デフォルトの名無しさん
07/01/09 10:04:22
くっ、スルー力が足りないっ
297:デフォルトの名無しさん
07/01/09 10:49:06
>>296
スラドにお帰りください
298:デフォルトの名無しさん
07/01/09 12:16:33
>>297
omochiの日記読んでしまって鬱
299:デフォルトの名無しさん
07/01/16 21:56:39
中田先生の本、ちゃんとした日本語でわかりやすいね。
しかし数学家のせいか、変な数式化するやつには参るな
A = {P,S}とか{a} = a |aa | aaa....とか
300:デフォルトの名無しさん
07/01/16 22:17:20
慣れれば普通だよ
301:デフォルトの名無しさん
07/01/20 16:58:13
パーサジェネレータとかって勉強するにはどういう本を探せばいいのでしょうか？
いままで自作言語ばっかり書いてきたんですけど、パーサジェネレータってもんがあることを最近知りました。
でも、勉強しようにも難しくてサイトみてもよくわからない状態です。
なにかわかりやすいオススメ書籍とかないでしょうか？
302:デフォルトの名無しさん
07/01/20 22:37:09
中田先生の本はアレだな。理論の説明はいいんだけど、その理論を実際どういうときに使うのかもう少し詳しく書いてくれればもっとわかりやすくなるな。
できれば１つ１つの理論とＣ言語のコードを対にして書いてほしい。
303:デフォルトの名無しさん
07/01/22 23:39:17
コンパイラの構成と最適化を読んでいて再帰的下向き構文解析のところまで読んだのですが、
構文解析と字句解析の区別がよくわからないのです。
再帰的下向き構文解析だと、例えば B -> aAb は
B(){ aを読む; A(); bを読む; } みたいになるのですが、
全ての生成規則を書いていくと
結局は字句解析がいらないことになってしまいませんか？
304:デフォルトの名無しさん
07/01/23 01:33:19
Wikipediaさんに聞くと良いと思うよ。
字句解析：入力を字句（プログラムの最小単位）に分割する
URLﾘﾝｸ(ja.wikipedia.org)
構文解析：字句同士の関係を解析するURLﾘﾝｸ(ja.wikipedia.org)
乱暴に単純化すると、字句解析は正規文法で扱える範囲を処理して、
構文解析は文脈自由文法で扱う範囲を処理する。
boost::spiritみたいに両者をシームレスに処理するのもあるけど、
普通は分割して扱ったほうが分かり易い。
305:デフォルトの名無しさん
07/01/23 17:37:37
>>303
字句解析しないということは、文字単位で構文解析することになるけど、
f 一文字を読んで、予約語の for なのか、ただの識別子なのか判断つかないのが下向き構文解析だとちょっと困る。
LR構文解析の場合は、字句解析を分けた方がメモリや計算の手間がだいぶ減るような気がする（今の計算機だと大した差ではないけど）。
306:デフォルトの名無しさん
07/01/23 19:06:48
C++みたいに、文脈情報が無いと字句解析できない場合はわけない方がいいのかも。
最近流行？ のcombinator parserも基本はわけないよね。
307:デフォルトの名無しさん
07/01/23 19:07:45
Lispなら（ｒｙ
308:デフォルトの名無しさん
07/01/24 20:40:02
>>306
あと、同じく最近流行？のPackrat Parserでも字句解析は分けないね。
個人的には、字句解析というのはあくまでLALRとかLLなどのよくある
構文解析アルゴリズムで処理できるようにするためであって、本質的には
要らないというか有害ですらあると思う。例えば、最近の言語だと文字列
(普通は字句解析で処理される)の中に式(構文解析で処理される)を埋め込む
ことができる言語が普通にあるが、こういうのは字句解析と構文解析が分かれて
いると非常に実現しにくい。
309:デフォルトの名無しさん
07/01/24 20:58:24
packrat parserって下降型のparserだっけ？
左再帰は大丈夫？
310:デフォルトの名無しさん
07/01/24 23:34:14
後戻りできるようなものを作ろうとすると、
字句解析と構文解析が分かれていたら非常にやりにくい。
311:デフォルトの名無しさん
07/01/24 23:56:34
ループ以外の左再帰って使う機会あるの？
312:デフォルトの名無しさん
07/01/25 23:13:20
>>309
左再帰はNG。そういうのは繰り返し(*)を使って書くのが定石。
右結合の演算子の場合は、右再帰で書くけど。
313:デフォルトの名無しさん
07/01/26 08:21:29
21世紀にもなったというのに、左再帰を人手で展開せなあかんのか…
あれ、文法が汚くなるから嫌いなんだよな
e ::= e + e | n
が
e ::= n (+ e)*
になるのはつらい。
314:デフォルトの名無しさん
07/01/26 12:03:23
>>313
まあ、その辺はトレードオフということで
ちなみに、俺はトップダウンparsing的な発想がデフォだから
左再帰を人手で展開するというよりも、展開系がまず先に
思い浮かぶ
315:デフォルトの名無しさん
07/01/26 20:44:33
>>301
自己レス。同じ疑問をもった人へ。
いまどきのプログラム言語の作り方
URLﾘﾝｸ(www.amazon.co.jp)
がいいと思う。
字句解析と構文解析がわかればどういうもんか一発で理解できると思う。
316:デフォルトの名無しさん
07/01/26 23:22:55
つ URLﾘﾝｸ(www.hpcs.is.tsukuba.ac.jp)
URLﾘﾝｸ(kmaebashi.com)
>2-3
まずはこんなところじゃね？
317:デフォルトの名無しさん
07/01/27 02:35:40
>>316
いや、自分にはこの↓説明がいかんかったです。
字句解析
ソースプログラムを、「字句(トークン)」の並びに分割する処理です。
構文解析
トークンの並びから、解析木を構築する処理です。
何度読んでもさっぱりわかりませんでした。
>>315の本はこのわからん部分がわかるのでいいと思いました。
これが他とちょっと違う部分です。
318:デフォルトの名無しさん
07/01/27 02:38:38
>>317
理論抜きでもｲｲから、他のちっこいスクリプトをまねして、
とにかく一回でも、実装してみれば、
ああーんそうか、って納得できるんだけどね・・・。
319:デフォルトの名無しさん
07/01/27 04:17:50
パーサコンビネータの論文ありますか？
320:デフォルトの名無しさん
07/01/27 13:27:52
最適化って、結局はグラフの操作がメインになるんだけど、
あれは、ややこしいねぇ・・・
（プロトタイプ的に）ナイーブな実装をしようとしただけでも、
普通のグラフライブラリなんて殆ど役にたたないし・・・
良いグラフライブラリがあれば、教えてください。
321:デフォルトの名無しさん
07/01/29 02:42:01
>>320
最適化って例えばどんなやつ？
それによって変わるような気がするけど。
322:デフォルトの名無しさん
07/01/30 07:53:13
>>321
"ほにゃららほにゃらら elimination" とか、
データフロー解析に絡む
あの一連のやつ。
323:デフォルトの名無しさん
07/01/31 00:31:19
>>322
フローグラフ上のデータフロー解析なら
自分で実装するのがたぶん一番楽。
データフロー方程式を解くシステムは昔からあったと思うけど
なんかいまいち流行ってないし。
最近はCTLモデル検査とかで最適化する人もいるらしい。
324:デフォルトの名無しさん
07/01/31 13:34:45
フローグラフ解析かぁ。
coins.flowあたりみればいいのかと思ったけど、さっぱりわからないです。
超簡単なソースどっかにないかなぁ。
325:デフォルトの名無しさん
07/01/31 16:59:50
>>324
coins.backend.ana.LiveVariableBitMap
とか結構簡単だと思われる。
326:デフォルトの名無しさん
07/02/01 23:47:32
>>323
手で書くのが難しいレベルの最適化って論理式で書けるの？
実行時間は？
327:デフォルトの名無しさん
07/02/02 02:26:28
>>326
データフロー方程式を解くのと同程度のことなら書けるらしい。
それ以上だとたぶん無理。
実行時間はデータフロー方程式解くのと同じくらいかと。
328:デフォルトの名無しさん
07/02/02 18:36:34
へー
おもしろそうだね
329:324
07/02/03 12:44:06
>>325
おおー、理解できる予感！！
「コンパイラの構成と最適化」を見ながらソース読んでみてます。
LiveVariableBitMapのBitMapはBitMapSetのことですよね。
BitMapSetクラスは単なる０か１かが入ってる配列の管理クラスみたいなもんと。
live variable 解析は「12.2.7 変数の生と死の解析」のこと。
この「変数の生と死の解析」の結果を使って「12.2.8 無用命令の削除」等が出来ると。
330:デフォルトの名無しさん
07/02/04 01:03:22
俺スクリプトがようやっと文字列結合まで回るようになった……
誰か、クラス設計とかで参考になりそうな資料ご存知ですか？
……Rubyのクラスを参考にしようかな
331:デフォルトの名無しさん
07/02/04 03:30:00
>>330
つ 諦めろ
332:デフォルトの名無しさん
07/02/04 04:39:42
>>330
URLﾘﾝｸ(www.squeak.org)
URLﾘﾝｸ(www.cincomsmalltalk.com)
333:デフォルトの名無しさん
07/02/04 11:21:15
squeakね。クラスはこんな感じか。
URLﾘﾝｸ(squeak.qp.land.to)
Collectionが充実しとりますな。何でそうなったかの経緯はわからんけど……
マクロ的なものが無かったからかね？
334:デフォルトの名無しさん
07/02/04 11:31:37
>>333
そこのサイト並べ方がよろしくないね。
継承関係がわかるように入れ子で表示するとコレクションがどういう方向でできてるのかよくわかるのに。
smalltalkならクラスブラウザで眺めるだけでいいから必要感じないのかもしれんけど、知らない人が見たらたくさんあってパニック起こすだけじゃないかと思った。
つーわけで330は一度squeakを実行してみるよろし。
335:デフォルトの名無しさん
07/02/04 12:02:38
>334
「自由自在～」持ってたので、それを参考にブラウズしてみました。
……すごい数ですな。GUI系を飛ばして眺めてみます。
336:デフォルトの名無しさん
07/02/06 23:24:01
質問です。
スクリプト言語を作ろうと思って、まずはC++でC言語コンパイラ作ってるんですが、
typedefの処理に困っています。
ソースファイル内の全ての構文解析完了後に、
構文木をたどって意味解析処理の一部としてtypedefの解析をしています。
この方法だと構文解析機がtypedefで定義された型名を使用して変数を宣言しようとしたとき、
typedef定義された型名を型名として認識できません。
解決方法として2つを考えています
・構文解析中にtypedefを検出してtypedef定義テーブルを作成する
・構文解析を2回行う(1回目はtypedefを含めたシンボルの検出、２回目が本当の構文解析？)
皆さんどちらの手法でやっているのでしょうか。
それとも、こんな現象は発生しない？
337:デフォルトの名無しさん
07/02/07 03:04:23
有名な問題なのでぐぐれ。
338:デフォルトの名無しさん
07/02/12 01:34:47
>>303
その疑問はもっともだと思う。
字句解析と構文解析が別れている主な理由は、
yaccを真似たコンパイラ・コンパイラが多いことと、
字句解析には字句解析ならではの問題があるため。
他には、コンパイラの教科書でも字句解析と構文解析が分けられている
ことなんかが挙げられるかもしれない。
一般的に字句解析では、構文解析で使われるLR(k)やLALR(1)よりも
一段制約が多く、より高速に動作する正規表現という文法を使う。
普通こういうことは考えないけど、
正規表現はLALRなどのよく知られている文脈自由文法により常に表現可能で、
(逆は無理な場合がある)
原理的には字句解析を構文解析に組み込むことはできる。
ただし、現実の字句解析が教科書的で単純な方法で行われることは稀で
普通は予約語のマッチを一通り試した後、
どれにもマッチしない場合はそれを識別子として扱うという
バックトラック的な処理が必要になる。
これが普通のLALRなどではできないので、
よく知られたコンパイラ・コンパイラ、yaccやbisonなんかでは
字句解析と構文解析を一緒にやることは無理ではないかと思う。
また、速度的な観点から避けられることもある。
一昔前(yaccが作られたのは1970年代)は、
パソコンの性能が今では考えられないくらい低かったし、
理論の構築も進んでいなかったので
この二つを分けることが絶対に必要だった。
もうこの考え方は古いのかもね。
339:デフォルトの名無しさん
07/02/12 04:57:43
無理してやればできるんでないの？
symbol ::= alphabet alpabet_or_digits
終端でない記号が爆発的に増えてコンパイルできなくなりそ。
遅延評価で空間量を時間量に置き換えてどうたらかな。
340:デフォルトの名無しさん
07/02/12 08:05:49
大まかに言うと字句解析は正則言語（⊆文脈自由言語）の解析、構文解析は文脈自由言語の解析なんだから、字句解析の部分も構文解析でできるに決まってるでしょ。
処理が二つに分かれている理由は、字句解析を有限オートマトン風に処理するアルゴリズムは、既知の構文解析のアルゴリズム（LL等）よりはるかに高速なこと。
それと構文解析木の底辺（＝字句解析前の入力文字列）を字句解析で押し上げれば、構文解析の入力の個数を（定数分の一に過ぎないが）減らせること。
木構造の性質を考えれば、底辺の要素数は、木全体の底辺以外の全要素数より多くなるでしょ（ε生成を除去できることから）。
基本的には理論的な背景がある。
341:デフォルトの名無しさん
07/02/12 16:20:44
正規言語を受理するlexerを、文脈自由言語を受理するparserで置き換えることができる
のは当然だが、これは今の話に余り関係ない。
字句解析-構文解析と処理をわけなかった時の一番の問題は、>338で言われている通り、
バックトラックもしくは予約語の最大長分の先読みが必要になること。
packrat parserはバックトラック演算子があるんだっけ？
342:デフォルトの名無しさん
07/02/12 16:43:34
>>341
packrat parsingではバックトラック演算子があるわけじゃなくて、
デフォルトの動作がバックトラック。つまり、
A | C
という式があった場合、まずAにマッチするかどうかを試して、失敗した場合Cを
試すという動作になる。ただ、これだけだと困る場合があるので、そういうときは
syntactic predicateという無限長の先読み演算子を併用することになる
343:デフォルトの名無しさん
07/02/12 19:05:13
なるほど。サンクス。
Cのparserでも書いてみるかな。
344:デフォルトの名無しさん
07/02/22 21:52:02
再帰下降構文解析をするときに、
深いところで起きたエラーを戻り値で次々と伝えて行くやりかたは
かっこ悪いですよね?
345:デフォルトの名無しさん
07/02/23 23:36:50
例外はどうでっしゃろ？
346:デフォルトの名無しさん
07/02/24 00:18:45
>>345
投げられない言語もあるからなぁ。
347:デフォルトの名無しさん
07/02/24 03:44:41
そこでデータとして定義したステートマシンを各文法ごとに用意して
スタックにそれのステートを積んで行き
本質的には再帰だけどループで実行できて
エラーがあったときはただそのループを止めるだけ
なんてのはどうでしょう
ギャグで言ってます
348:デフォルトの名無しさん
07/02/24 05:59:51
人間bison!
まさかコレが「件」って奴？
349:デフォルトの名無しさん
07/02/24 11:07:55
>>345
if( !is_ident(context) ){
throw syntax_error("hoge hoge");
}
こんな感じのプログラムが、カッコいいとは到底思えない俺がいる
350:デフォルトの名無しさん
07/02/24 15:00:14
再帰だとスタックを使い過ぎてオーバーフローしないだろうかと
不安だった、そういう時期が僕にもありました
351:デフォルトの名無しさん
07/02/25 05:04:58
Rubyのインタプリタはスタックオーバーフローで死んだりする……
352:デフォルトの名無しさん
07/02/26 08:53:12
どんだけスタック食いつぶすスクリプト書いたんだｗｗｗ
353:デフォルトの名無しさん
07/02/26 19:14:21
>>352
Mac OS Xのデフォだと簡単に食いつぶす。
なのでulimitでスタックの制限をunlimitedにしなきゃならん。
354:デフォルトの名無しさん
07/02/27 20:25:27
>>352
たらいまわしとかだろｗ
355:デフォルトの名無しさん
07/03/02 02:44:15
>>354
スクリプトの実行でスタック食いつぶすなら再帰呼び出しすればいいだけだけど、インタプリタのスタックを食いつぶすってことは、やたら深いネストや式を自力で書くとか（もしくは何らかのプログラムでわざと生成？）しなきゃ無理ですな。
356:デフォルトの名無しさん
07/03/02 02:54:05
>>355
……え？
357:デフォルトの名無しさん
07/03/02 03:00:47
なるる
358:デフォルトの名無しさん
07/03/03 23:21:19
ちょっと質問良いですか？
行末に対してはセミコロンを省略しても良いようにしたいんですけど、
pnuts がやってるみたいに 『改行入れても良い部分を全部明示的に指定する』 よりもっとスマートな改行な方法あります？
当方 JFlex と Jay を用いております。
359:デフォルトの名無しさん
07/03/04 08:46:19
>>358
Pnutsのような方法以外だと、Lexerに改行を無視する状態と無視しない状態の
２つの状態を持たせて、ParserからLexerの状態を明示的に状態を遷移させる
という方法がある。ただ、それほど楽にはならないと思うけど。
360:デフォルトの名無しさん
07/03/17 12:21:14
>>358
つまりPnuts式はStatelessなlexerであり、lexerは楽できるけどParserがめんどい。
>>359の方法はlexerがstatefulになって少し面倒くさくなるぶんparserがすこし楽になる。
トレードオフだな。
しかし昔に比べて過疎ってるな。
361:デフォルトの名無しさん
07/03/17 23:54:30
俺言語を造っている変態が減ったんだろ
……俺言語の設計ってけっこう楽しいけど、破綻しないように作るのはしんどいよね。
362:デフォルトの名無しさん
07/03/18 15:23:34
構造体についての実装方法が載っている良書を教えてもらえませんか？
サンプルソースがあるとベターです
どうもCのサブセットと言いつつ構造体を省いている本しか持ってないので・・・
363:デフォルトの名無しさん
07/03/18 15:39:23
別に何を悩むこともないと思うんだが。
364:デフォルトの名無しさん
07/03/18 15:48:44
磯Cでいいんでない？
365:デフォルトの名無しさん
07/03/18 15:50:43
それが関数の呼び出しで詰まりまして
ある関数のreturnで構造体を返した場合ですが
呼び出し前に返値用のスタックを確保しておいて
そこにreturnのときにコピーするようなまどろっこしい方法しか思いつきません。
それと、動的配列を有している構造体など
どうしてるのかいなと思いまして
366:デフォルトの名無しさん
07/03/18 15:56:41
磯Cてなんですか？検索掛けたら考古学関連がでましたが・・・
367:デフォルトの名無しさん
07/03/18 16:01:48
動的配列のポインタを持っている構造体で無く？
そのものを持っているのですか？
368:デフォルトの名無しさん
07/03/18 16:04:55
>>366
ＣはISOでも標準化されてる
たしか言語そのものともうちょっとこまごまとしたものがあったはず
URLﾘﾝｸ(ja.wikipedia.org)
てかアライメントさえ気をつければいいだけなんじゃないか？
> そこにreturnのときにコピーするようなまどろっこしい方法しか思いつきません。
それでいいんじゃなかったかと
369:デフォルトの名無しさん
07/03/18 16:05:59
ついでに呼び出し既約
URLﾘﾝｸ(ja.wikipedia.org)
370:デフォルトの名無しさん
07/03/18 16:10:44
そこらがどう実現すればいいのか解らないのですが
やりたいことは、
struct test
{
string s;←これを動的にしたい
int i;
}
のような感じです
371:デフォルトの名無しさん
07/03/18 16:12:10
>磯Ｃ
なるほどISoのことでしたか。
有り難うございます見てみます。
372:デフォルトの名無しさん
07/03/18 16:54:50
>>370
stringって何者？
373:デフォルトの名無しさん
07/03/18 17:24:34
>>372
流れからして>>362のスクリプトにあるファーストオブジェクトだと思うが
動的にサイズが変わるんだとiへのオフセットも毎回変わるの？
374:デフォルトの名無しさん
07/03/18 19:11:26
>>370
普通
struct string {
size_t currentBufSize;
char *pStrBuf;
//なにやらいろいろ定義
};
とかなってないかえ？
375:デフォルトの名無しさん
07/03/20 17:21:18
日本語が扱えないと話にならないコンパイラを作ることになったのですが、
マルチバイト文字の扱いが一番楽なパーサジェネレータはどれですか？
Unicode固定でいいです。
・日本語を含む文字列を普通に解析できる
・文法定義中でも日本語が使える(\uxxxxのような書き方でなく)
SableCCはどちらもいけるようですが、ドキュメントが貧弱なので不安です。
ANTLRは後者が駄目でした。
376:デフォルトの名無しさん
07/03/20 21:59:16
パーサと文字コードは全く関係ない。
字句解析コードも出力する機能があるタイプなら関係する。
たとえば私は今、lemonを使ってるけどトークン番号を渡すだけ。
377:デフォルトの名無しさん
07/03/20 22:34:26
rubyのraccは字句解析部分をrubyのパターンマッチで記述しているので日本語もいけそう。
構文解析やその他の部分で機能が十分かどうかは不明。
378:デフォルトの名無しさん
07/03/20 23:11:19
raccでHTML用のテンプレートエンジンを作ったけど、特に問題なしです。
……まあ、UTF-8のみでOKなら、ダメ文字もバイト切れ目問題も無いから
あんまり気にする必要が無いような気がするけど……
379:デフォルトの名無しさん
07/03/21 04:54:50
>>375
日本語はparserでなくlexerの方の問題では？
380:デフォルトの名無しさん
07/03/21 07:25:13
lexのもんだいだよな・・・
381:デフォルトの名無しさん
07/03/21 09:24:02
URLﾘﾝｸ(www.mainichi-msn.co.jp)
訃報：Ｊ・バッカスさん８２歳＝コンピューター言語開発者
ジョン・バッカス氏（コンピューター言語の開発者）ＡＰ通信が２０日
伝えたところによると１７日、オレゴン州アシュランドで死去。８２歳。
デラウェア州ウィルミントン生まれ。米コンピューター大手ＩＢＭで１
９５０年代に、プログラム作業の大幅な効率化に貢献したコンピューター
言語「フォートラン」を開発。コンピューターが扱う言語の文法を定義す
るのに用いる「バッカス・ナウア記法」も開発し、今日でも幅広く使われ
ている。７７年にコンピューター分野のノーベル賞といわれるチューリン
グ賞を受けた。（共同）
382:デフォルトの名無しさん
07/03/21 09:31:15
正規表現を状態遷移図に変換するツールalamo。
現在WIN32バイナリのみリリース、
まだシフトJISのみ入力可能。
使用方法：
標準入力から正規表現を入れると標準出力にdot言語のソースが出力される。
A>alamo < textfile | dot -Tjpg > out.jpg
トンプソンの構成法でなくεを消去した状態のNFA。
出力をファイルに落としてからUTF8に変換すれば漢字も出た。
URLﾘﾝｸ(capslockabcjp.kitunebi.com)
※動作条件としてURLﾘﾝｸ(www.graphviz.org)が必要
383:デフォルトの名無しさん
07/03/21 10:00:12
>>381
うお、マジか。ご冥福をお祈りします。
384:デフォルトの名無しさん
07/03/21 10:41:19
「可愛そうなジョージ、病気になる前まではソートルーチンもちゃんと動いていたのに・・・」
385:デフォルトの名無しさん
07/03/21 14:03:48
>>384
これなんだっけ!?すげーみたことあるんだけど・・・・
386:デフォルトの名無しさん
07/03/21 16:16:51
ｽﾚﾘﾝｸ(scienceplus板)
【訃報】ジョン・バッカス氏 FORTRANを開発
387:デフォルトの名無しさん
07/03/21 17:07:33
>>384
本物のプログラマおつ
388:デフォルトの名無しさん
07/03/21 23:25:45
lemonがWindows上ではlemapar.cがカレントにないと動かないので、
調べてみるとlemonのpathsearchという関数がバグっている。
6行程度の修正で直る。
URLﾘﾝｸ(capslockabcjp.kitunebi.com)
389:デフォルトの名無しさん
07/03/22 13:50:39
かわいそうなのはジョージじゃなくてソートルーチンなんだろ。
390:デフォルトの名無しさん
07/03/22 14:03:45
ジョージかわいいよジョージ
391:デフォルトの名無しさん
07/03/22 18:31:34
どうしてもMOTHERを連想する
392:デフォルトの名無しさん
07/03/24 17:14:38
ＭをとったらＯＴＨＥＲ、他人です。
393:デフォルトの名無しさん
07/03/24 18:15:58
other単体では他人になりません。
394:デフォルトの名無しさん
07/03/26 13:12:56
another
395:デフォルトの名無しさん
07/03/26 14:16:18
bother
396:デフォルトの名無しさん
07/03/28 12:12:32
商用ゲームで使うスクリプトのコンパイラ・エンジンを作ることになったんですが、
そういったプログラムに関してはわからないことが多いので悩んでいます。
組み込み系言語のLuaを使うという選択肢もあるんですが、とりあえず自作する方向で勉強してます。
flex&bisonあたりは使うつもりなのですが、他にも使って便利なツールってあるでしょうか？
初心者はnasmとかalinkみたいなものを使った方がいいんでしょうか。
397:デフォルトの名無しさん
07/03/28 13:20:54
ANTLR
398:デフォルトの名無しさん
07/03/28 14:13:22
なぜLuaを使わないかの理由が知りたい。
399:デフォルトの名無しさん
07/03/28 16:30:15
何故インタプリタ型のLuaとコンパイラ型の言語設計(nasmなどを挙げている事から
の類推)を並べているのか分からないのだけど、コンパイラ作るだけならパーサ
ジェネレータ以外に必要なものは無いし、それ以上の補助ツールも無いと思う。
nativeに落とすのであればWindowsならcoffなどのフォーマット参照、コンソール
なら各ベンダの資料とか、自前でニモニックを変換するのはかなり泥臭い話なんで
可能ならnasmとかを使う方が遥かにお手軽、最適化を自前実装するのでなければ、
期待できるコンパイラの性能にも拠るけどCとかにトランスレートする方が高速な
動作を期待できるかもしれない。
というかゲームの種類と環境でコンパイラなのかVM型のインタプリタとかで良い
のか、デザイナー向け簡易スクリプトなのか汎用言語タイプなのか良く分からない。
単純に上から言われたのならもう少し何が欲しいのか詰めた方が良いんじゃないかと
心配してしまったのだけど。
400:デフォルトの名無しさん
07/03/28 16:55:23
BNFのコンフリクトを解決しやすいツールって何かないですか？
401:デフォルトの名無しさん
07/03/28 20:08:47
つ-vオプション
402:デフォルトの名無しさん
07/03/28 21:28:51
つ熟練者の直感
403:デフォルトの名無しさん
07/03/28 22:08:45
>>399
具体的なことを言えば、
社内のスクリプトのシステムを作っていた前任者が大分前に辞めてしまい、
いい加減作り直さなきゃね、という状況で自分がやることになり、
前任者の作ったものを解析した結果、
yac&lexを使い、自前ツールでアセンブリ言語に変換し、そこから先はnasm+alinkのようなツール（実際は別物）
でマシン語にしたものを実際のゲーム側で読み込んで使っていました。
それで、そういう方向でいろいろ調べているという状況です。
>>398
Luaは存在は知っているのですが、具体的なことはまだ知りません。
上記のような状況なので調べるものとしてLuaの優先順位が今は低いだけで、
一度しっかり調べて検討するつもりです。
404:デフォルトの名無しさん
07/03/28 22:40:22
>>403
>yac&lexを使い、自前ツールでアセンブリ言語に変換し、そこから先はnasm+alinkのようなツール（実際は別物）
>でマシン語にしたものを実際のゲーム側で読み込んで使っていました。
それは「スクリプトのシステム」ではなく、「コンパイラ」ではないかと・・・
405:デフォルトの名無しさん
07/03/28 22:59:46
難儀ですな、、、
自分がコンパイラ作った時はyaccで文単位で構文木を作ってそれをリストに格納、
ニモニック変換時は各文ごとに構文木を辿ってテンプレートに従ってコード出力、
言語に型システムがある場合はニモニック生成前に構文木を一旦辿って型の文脈
を決定、その後ニモニック生成ってカンジですた。
自分の場合スタック型VMだったんでレジスタ割付の最適化とかは知らない、アキュムレータ
とメモリ間接に限定すれば簡単だけど、アセンブラがシンボル対応ならアドレス解決
は不要かな。
後はリファレンスカウンタまでならNativeでも比較的安易に作れるけどFull GCだと
スタックや変数領域をどう扱うか、スレッドの管理までフレームワークを用意する
形なのである程度事前設計が要ると思う。
まぁ参考になるか分かりませんが、、、
406:デフォルトの名無しさん
07/03/29 00:08:48
もう前任者のはいったん捨てた方がいいかもシレン
ちゃんとしたドキュメントがあるなら別だが
407:デフォルトの名無しさん
07/03/29 01:00:32
>>406
レオもそう思う
408:デフォルトの名無しさん
07/03/29 01:40:53
>>403
>でマシン語にしたものを実際のゲーム側で読み込んで使っていました。
ここまでやってるってことは、普通にインタプリタじゃパフォーマンスが足りないってことかな？
なら、CやＣ＋＋言語へのトランスレータ作ったほうが簡単だし、
工数もかからないんじゃないかな。
俺は商業じゃないけど、EXCEL->C++へのトランスレータ作って使ってる。
場合によってはC++そのままの機能も埋め込めるし、既存言語に足りない機能足すだけだから、
それこそあっという間に完成するぞ。
409:デフォルトの名無しさん
07/03/29 06:38:39
ちなみにLuaのVMはJITを搭載しているから、他のスクリプト言語と比べてバフォーマンスはだいぶ高い。
410:デフォルトの名無しさん
07/03/29 12:01:35
>>404-409
返答ありがとうございます。参考になります。
>>408
最低限のレベルで要求されているのは、メモリや速度の面で問題ないということと、
前任者のスクリプトがCライクな仕様で、社内メンバーがそれに慣れているので
それに合わせなければなりません。
>>409
とりあえず、前任者のものをある程度理解できたのでこれからLuaを勉強しようと思ってます。
411:デフォルトの名無しさん
07/03/29 16:26:26
>>410
作りなおすってことは、前任者の作った言語に不満があるってこと？
どんな不満があるのか（機能が低い、言語使用が貧弱、とか）によっても
作り方が変わってくるんじゃないかと思う。
（トランスレータにするのか、インタープリタで間に合うのかとか…）
412:411
07/03/29 16:27:10
訂正：言語使用 → 言語仕様
413:デフォルトの名無しさん
07/03/29 18:04:54
>>411
いくつか解決しなければいけない問題というのはあります。
トランスレータというほどじゃないですが、それを解決する方向で拡張するという案も確かにあります。
ですが、作った人間がすでに会社にいないので、理想を言えば新しいものを用意することでしょう。
自分が辞めれば結局同じことのループなので、Luaのようなものを使うのが会社にとっては一番いいことなのかもしれません。
LuaはCライクな言語じゃないようなので今はSquirrelを見ています。
414:デフォルトの名無しさん
07/03/29 18:13:32
ちうか速度面で劣化があっちゃまずいのならインタープリタじゃアレなんじゃね？
前任者さん版のスクリプトのおぼろげな仕様聞く感じ
415:デフォルトの名無しさん
07/03/29 18:53:22
>>414
まあ、マシン速度も昔に比べれば比較にならないくらい向上してるし、
どうしても速度的に問題があるなら、、その部分だけゲームエンジン本体に
直接機能追加すればいいから、そんなに問題になることはないんじゃないかな？
自社ツールなら、そこらへんどうとでもなる。
今までＣライクなスクリプトだったなら、Ｃ言語へのトランスレータが簡単でパフォーマンスに
優れていると思うけど、フリーの汎用エンジンなら自社でメンテナンスしなくていいから
将来的な負担を考えると、悪くない選択かもね。
とはいえフリーのスクリプトエンジン使う場合、ライセンスをちゃんと確認しておかないと、
へたすりゃソースコード公開させられる羽目になるぞ。
416:デフォルトの名無しさん
07/03/30 14:36:03
>>409
LuaJITってLuaの大本にマージされたの？
417:デフォルトの名無しさん
07/03/30 14:59:01
>>410
>前任者のスクリプトがCライクな仕様で、社内メンバーがそれに慣れているので
メンバーにCを覚えさせたほうが速いんじゃね？
っていうか、そのスクリプトの「利点」って何なの？
418:デフォルトの名無しさん
07/03/30 15:07:55
>>413
>Squirrel
これ知らんかった。Luaもいいけど、これもよさげだね。さんくす。
419:デフォルトの名無しさん
07/03/30 15:13:21
> メンバーにCを覚えさせたほうが速いんじゃね？
んなこたーねえｗ
420:デフォルトの名無しさん
07/03/30 15:20:24
>>419
そのスクリプトの仕様を見てみないと
なんとも言えないと思うが？
話を聞く限りでは、汗を生成していたんだろ？
実はそれ、ただのCコンパイラ(多少の独自拡張あり)かもよ。
421:デフォルトの名無しさん
07/03/30 16:49:28
ていうか話聞いてるとSystem4.0が思い浮かんでしょうがない
422:デフォルトの名無しさん
07/03/30 18:52:06
自動でマルチスレッド化、グリッド化
できるコンパイラないの？
423:デフォルトの名無しさん
07/03/30 19:00:27
Intel C++ Comipilerは？
424:デフォルトの名無しさん
07/03/30 23:35:18
Cライクなスクリプトと言うと、smallというのもあったねぇ。今はPAWNか。
URLﾘﾝｸ(www.compuphase.com)
……どんなのか知らんけど……
425:デフォルトの名無しさん
07/03/31 13:49:03
>>424
ちょっと使ってみたことがあるが、スクリプトで動的メモリ割当てを使わない場合は
GCを切ることができたり、（再帰がなければ）スタックの最大長をコンパイル時に計算して、
スクリプトのロード時にVMに割当てるメモリを最小限に抑えたり、組込み機器向けにいい感じ。
スクリプトの文法としては、Cライクな手続き的記述に加え、状態遷移、イベント駆動的な
書き方が出来るのも面白い。
426:デフォルトの名無しさん
07/04/01 01:12:36
verilogのパーサがほしくて
cygwin + antlrをインストールした後
URLﾘﾝｸ(www.eecs.berkeley.edu)
からダウンロードしてみました。 flex とbisonは入れていません。
makeしてexeファイルが作れて、adder.vという例題ファイルをexeに食わしてみたのですが、
Parsing Verilog file...
... successful!
というメッセージが出たのですが、ファイルが生成されません。どこかにできているものでしょうか？
ご存知の方いたら教えてください。
427:デフォルトの名無しさん
07/04/01 03:40:32
>>426
君は何年生？ （どこの大学？ 専門学校？）
それと与えられた宿題の内容も詳しく教えてくれた方が役に立つアドバイスができそう．
まずexample.cppをエディタで開いてみるところから始めよう．
428:デフォルトの名無しさん
07/04/01 08:01:20
社会人
一応全部見たが出力先がよく分からんから聞いた。煽りにレスしてしまった・・・
429:デフォルトの名無しさん
07/04/01 09:21:12
まぁ、あまりに青臭い煽りにはつい優しくしてあげたくなることもあるｗ
430:デフォルトの名無しさん
07/04/01 10:11:45
パーサはパースする物。
サンプルはパースするところまで。
VHDLを読んで解釈する、そして文法的には正しく読み込めたと表示。
その中身を変換して出力するのはパーサの仕事じゃない。
431:デフォルトの名無しさん
07/04/01 18:18:39
>>430
えーと、中身を解釈して構造はこうだったよ！と
吐き出してくれるものってないのでしょうか？
構造解析結果まで生成するものがパーサだと思っていたのに・・・
432:デフォルトの名無しさん
07/04/01 18:32:20
>>431
おいおい、今朝教えたパーサの知識を
早速こんな所で御開陳か？
>>430の話は、要するにサンプルコードはパースはするけど、
内部的に生成した構文解析データの出力ルーチンは記述されていない
ってだけの話だろ。
433:デフォルトの名無しさん
07/04/01 20:34:24
>>432
すみませんが、もう煽りにレスはしません
434:デフォルトの名無しさん
07/04/01 20:43:18
いや、煽ってなどいない。
そもそもキミは質問に回答をもらった後で、
回答者に感謝の意を表しているかね？
435:427
07/04/01 20:51:45
>>431
example.cpp（と，そこで使ってるverilogParser.yxx）は
* エラーがあったらyyerrorのassert(false)で異常終了
* なかったら返り値1で終了（←何考えてるんだ？）
ってだけのプログラムなのは読めば分かるだろ？
そもそも出力先を一つもfopenしてないしfstreamも使ってない
内部構造はyydesign->modulesにpush_backされてるから自分で文字列化しる
つまりverilogDesign.cpp内の各クラスにoperator string()を追加するんだよ
とりあえずverilogパーザなんて難しいものでなく逆ポーランド電卓から始めた方が ｗ
436:デフォルトの名無しさん
07/04/01 20:52:02
フレームの最中申し訳ないが質問に答えてほしい。
今日、電車の中でふと疑問に思った。
様々なLispやOCamlみたいにevalを持つコンパイラの場合
実行コード中にインタプリタかコンパイラを持っているのですか ?
FAQかも知れませんが教えてください。
437:デフォルトの名無しさん
07/04/01 20:59:53
>>436
実行コード中にインタプリタかコンパイラを持っています
438:デフォルトの名無しさん
07/04/01 21:45:01
>>436
Lispコンパイラとか言うときってスタンドアロンなバイナリファイルを吐くものでないことが多い気がする
対話環境（←コンパイラを含む巨大なプログラム）において関数を定義すると
その関数に対応するネイティブコードをコンパイラがメモリ上に構築してそれを実行，とか
そういうのだと作ったソフトの配布には使いづらい（そうでないものもある）
OcamlのToploopモジュールも，あれocamloptじゃ使えないんじゃないのか？ （未確認）
439:436
07/04/01 23:37:28
>>437 >>438
レスありがと。
やっぱ魔法みたいな方法はないんだね。
440:デフォルトの名無しさん
07/04/02 01:49:19
>>438
インクリメンタルなコンパイルのほうが将来性があると聞いて、そっち方面に
手をつけてるんだけど、↓の意味がわからない。コンパイラを含む分、サイズ
が多きくなるけど数メガ程度で、Windows でいったら DLL HELL を避けるため
に C ランタイムとかの DLL を添付程度のもんだとおもってるんだけど、
サイズ以外になにか問題ってある？ Java や Lua の JIT とかも該当しそうだけど
> 対話環境（←コンパイラを含む巨大なプログラム）において関数を定義すると
> その関数に対応するネイティブコードをコンパイラがメモリ上に構築してそれを実行，とか
> そういうのだと作ったソフトの配布には使いづらい（そうでないものもある）
441:デフォルトの名無しさん
07/04/02 02:18:08
LexerとParserが分離できるかの問題じゃね？
xml知ってるならDOMを実装するのにSAXが使われてたりするってのをイメージすると分かりやすいんだが。
字句解析が中のSAXパーサ、構文解析がDOMパーサ全体。
構文ツリーがDocumentノードって感じ。
分離するかしないかの問題でそれと同じだ。
442:デフォルトの名無しさん
07/04/02 02:39:20
サイズの問題さえ気しなけりゃ配布ソフトが字句解析器や構文解析器を備えてようが、
それが分離できるかできないかなんて関係なくない？
443:デフォルトの名無しさん
07/04/02 03:29:52
つーか対話環境ってそんな大きくなるもんかね？
444:デフォルトの名無しさん
07/04/02 07:42:23
REPLだけが対話環境とは限らんから、Visual Studioみたいな対話環境が
ついてくるのかも知れないじゃんw
445:デフォルトの名無しさん
07/04/02 22:37:36
商用利用（ゲームとか）を考えると、ソースや開発環境をまるごと載っけてると
勝手に改変版のプログラムを売られる/配られるのが嫌だ。とかいうのはあるかも。
446:438
07/04/03 00:07:09
>>440
とりあえずサイズの問題だけ考えてた
まぁ今時では気にしなくていいのかな？
こないだ見た例では，abenori氏のTeXインストーラがDLL版Rubyを同梱してたっけな
>>445
特にLispはリフレクション，イントロスペクション周りの機能が多いので
対話環境をそのままくっつけておくと
意図せずに内部を見られ，いじられてしまうことにつながりかねないよね
（それは強みの裏返しだが）
447:デフォルトの名無しさん
07/04/03 01:32:42
>>498
サイズの問題がメインなんだよね。まぁ、いじられたくないアプリなら対話環境の機能は殺したいよね。
JIT みたいなインクリメンタルなコンパイル機能に問題があるのかとガクブルしちまった。すまん。
Lisp 界隈では大抵コンパイラというのはソースをネイティブコードやバイトコードなどの実行形式に変換する
機能のことで、スタンドアロンなバイナリ作る機能とは独立してるみたいだね。うーむ、そーゆうのもアリなんだねぇ…。
448:デフォルトの名無しさん
07/04/03 03:24:05
＞スタンドアロンなバイナリ作る機能
それはリンカとかローダとか（名前は何でもいいんだけど）
別のプログラムの役割では
449:デフォルトの名無しさん
07/04/03 16:58:13
極力ランタイムをmsvcrt.dll直にしてnativeに落とせば2KBぐらいから作れる。
VM上で動くのなら10～20KBぐらいじゃないかな。
eval相当が必要かどうか。
450:デフォルトの名無しさん
07/04/04 00:23:27
ココで聞くべきことではないかもしれないけど
組み込み用(マイコンとかじゃなくLuaなどの方面)のCコンパイラ(スクリプトか？)があったような気がするんだけど
名前が思い出せない
知っている人はいますか？
たしか、機械語を吐けるものだった気がします
451:デフォルトの名無しさん
07/04/04 03:34:16
これかな？
LSI C 86
452:デフォルトの名無しさん
07/04/06 17:00:33
こっちかも
libtcc
453:デフォルトの名無しさん
07/04/06 18:58:21
tccか… あれはいいものだ。
454:デフォルトの名無しさん
07/04/17 16:47:20
訳あって、(メトリクス計算プログラムを作るため)字句解析まで行いたいと思っている者です。
Javaで調べてみたところ、java.io.StreamTokenizerというAPIが自動で構文解析をやってくれるそうなのですが、
このスレ的にはStreamTokenizerの評価はいかがなものでしょうか？
ちなみに、字句解析までのプログラムを（OS云々で面倒なので）Javaで作ろうと考えており、
扱う言語もとりあえずはJavaSE1.4あたりにする予定です。
できれば、StreamTokenizerを詳しく取り扱っている本とかを紹介していただけると助かります。
455:デフォルトの名無しさん
07/04/17 17:13:17
>>454
URLﾘﾝｸ(java.sun.com)
456:デフォルトの名無しさん
07/04/17 17:14:16
間違った
URLﾘﾝｸ(sdc.sun.co.jp)
457:デフォルトの名無しさん
07/04/17 17:18:34
>>454
字句解析・構文解析・意味解析のそれぞれの意味の違いを知っていますか？
458:デフォルトの名無しさん
07/04/17 17:30:49
StreamTokenizerで扱えるトークンは
・ 数値
・ ワード (英数字のつらなり、文字列定数、その他の記号)
・ 行末、ファイル末検出
* コメント記号(#等)以降行末まで読み飛ばし
程度。任意のトークンを追加登録する機能はない。
簡単な設定ファイル程度ならともかく
Java言語の字句解析には機能不足だ。
Java言語の構文解析が目的ならば、
パーサ生成プログラムを使うって作るか、
ありもののパーサを探すのが良い。
459: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
あいまいも糞も一回でもやってみりゃわかるでしょ
わからない人とはお話ししませんｗ
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
そういうのもそうだな
あとダブルコーテーションの中身が豪勢なのも俺は嫌いだ
あとなんだったかな
なんかもっと個人的に微妙なんだけど凄く嫌なのあったんだけど忘れたｗ
今度メモってくる
誰か解決策知ってるかもしれんし
483:デフォルトの名無しさん
07/04/17 23:30:25
改行とかタブとか見えないのが構文に影響を与える言語早く廃れてほしい
パイソンとかもう消えていいよ
484:デフォルトの名無しさん
07/04/17 23:38:42
>>479
a---3 は特に字句解析で困ることはなし。
マイナスが連続した場合の処理だけど、
１．１つめのマイナスを読み込む。
２．1文字先読みする。
３a．２で読んだ文字がマイナスなら演算子--（マイナスふたつ）と判断。
３b．２で読んだ文字がマイナス以外なら演算子-（マイナスひとつ）と判断。
ってだけで済む。
>>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)
は関数呼び出しという問題のことでおｋ？
この場合必要なのは意味解析から構文解析へのフィードバックであって、
字句解析は関係ないような。
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
ミスは見なかった事にしてあげようｗ
513:デフォルトの名無しさん
07/04/18 09:22:42
>>489
> >>484
> 3---a
うん。だから、それは
「３」「－－」「－」[a」
の４つのトークンに解析されるから文法エラー。
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)は、
(少なくとも)２種類の解釈ができる。
解釈1. XXXXが関数名の場合
関数XXXXの呼び出しと解釈する。
XXXX("foo", stdout) と等価。
("foo", stdout) は関数の引数と解釈する必要がある。
解釈2. XXXXが型名の場合
型XXXXへのキャスティングと解釈する。
("foo", stdout) は式と解釈する必要がある。
意味解析： 識別子XXXXの定義を調べ、
構文解析フェーズのどの解釈が適切か判断する。
但し実際のCコンパイラは１パスでこれを処理するので、
構文解析フェーズで式(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
ここはひどい揚足鶏スレですねｗ
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
ｗｗｗ
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
おこちゃまむけせつめい
（１）ていぎぶのしょり１
"typedef int a;"
字句解析くん： 予約語(typedef)、組込み型(int)、識別子(a) ";" ｷﾀー
構文解析さん： typedef文ｷﾀﾜｧ・・・組込み型(int)、型識別子(a) って感じ？
意味解析先生： 型テーブルに登録しときますね。
型識別子｜型
--------+-------------
a ｜int
（２）ていぎぶのしょり２
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
意味解析持ち出したアフォに話を合わせといたら、
ついにアフォが自分の掘った穴にはまったなｗ
変数テーブルや型テーブルの管理は、
構文解析の仕事だよ
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)は、
>(少なくとも)２種類の解釈ができる。
こんなのダメダメ。実質、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
あーうるせー
俺のいない間にスレ進み過ぎだろ
全部読むのに苦労したぜ
結局さ、字句解析と構文解析なんてわざわざ分けるだけ面倒なだけでしょ
俺が週末に趣味で作ってるスクリプト言語が完成するまで
反論は一切許さない
このスレにくるたび最良の方法が目移りしてなかなか作業が進まない罠
年内に公開はもう無理だと思うｗ
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
ググってページ示すのがやっとで
内容理解できない人だからしようがないｗ
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だが、俺が例に出した式を埋め込める文字列リテラルというのは、
そのミニ言語がその言語自身なわけで、もう１つ言語エンジンを作るのは
無駄でしょ。しかも、その埋め込まれた式が構文的に間違っていたら
構文解析エラーを出す必要があるから、言語エンジンを再帰的に適用する
なんて方法でもダメ
で、実際はどうするかというと、状態付きLexerにして、ParserからLexerの状態を切り替えるか、
そもそもLexerとParserを分ける必要が無い構文解析アルゴリズム(Packrat Parsingなど)を
使うわけだ
570:デフォルトの名無しさん
07/04/18 23:32:02
>>568
宗教選択じゃねぇんだから、目的考えて自分で解決しろ。
スミスっぽい方が >>569に来てるから、相談したらどうよ。
>>569
> 構文解析エラーを出す必要があるから、言語エンジンを再帰的に適用する
> なんて方法でもダメ
ダメな理由をｋｗｓｋ
571:デフォルトの名無しさん
07/04/18 23:39:32
Packrat Parsingで効率良いパーサ書けますって言いたいだけじゃないか、とｗ
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で効率良いパーサ書けますって言いたいだけじゃないか、とｗ
まあ、半分くらいはそのような意図が無いでもない
> で具合はどうよ
これはどういう意味？
575:デフォルトの名無しさん
07/04/19 00:06:29
>>531
遅レスだが。
丸投げするような仕事は、
そもそもSIer内部で誰も興味ない
つまらない仕事だから丸投げ＆ﾋﾟﾝﾊﾈするだけだろう
本筋をちゃんと説明せず
関係ない話でお茶を濁すのは
醜いよ
576:デフォルトの名無しさん
07/04/19 00:16:18
> > で具合はどうよ
> これはどういう意味？
ｪｪｪｴｴｴエエエ
そこでこっちに投げるか?普通
たとえば
・バックトラックやconflictを避けた素直なパーサを書きやすいか
・処理時間がリニアで高速か
とかそんな話じゃなかったっけ
ちゃんと見てないけど
577:デフォルトの名無しさん
07/04/19 00:31:06
なんでおまいら今日に限ってこんなにスレ消費が速いんだよｗｗｗｗｗｗｗｗｗｗ
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
おまんまんらめえー
らめなの！そんな太いの入るわけ無いじゃない！
５００ｋバイトのソースファイルなんて私には無理！
い…いや！ひぃー
（ギチギチ）
あ…あたまがおかしくなっちゃうの…
もう駄目…オーバーフローして…しまう
「」さん…ごめん…げふ
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
発言は幼く、態度は横柄
こりゃとんだ学生さんだなｗ
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なんて２種類の正規表現が用意されているし。
RFCもないだろうから、好きなように実装すればいいと思うよ。
607:デフォルトの名無しさん
07/04/21 19:39:06
以上、自問自答でお送りしました
608:デフォルトの名無しさん
07/04/21 19:49:00
Internet Engineering Task Forceが正規表現の標準を決めるという発想に度肝を抜かれたｗ
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
こいつは問題定義を明確にせずに
議論をかき回す常習犯だからｗ
617:デフォルトの名無しさん
07/04/22 10:12:42
これくらいエスパーしてやれよ
お前ら役立たずだな
618:デフォルトの名無しさん
07/04/22 10:24:14
ほら来た半島人
619:デフォルトの名無しさん
07/04/22 10:26:57
掲示板で乱射事件起こしまくりのチョンｗ
620:612
07/04/22 11:57:00
あらら、なんかもめてますね。ごめん。
C++で俺言語作っているんだけど、どうせならForthやLispみたいにソース読み込み時の
挙動についても言語内に取り込んで拡張できるようにしたいなぁ、と考えたのが背景。
Lispのリードマクロとか、Forthみたいなスペース区切り必須にしてもいいけど、文脈自由文法に
対応できたらいいなぁ。でも、自分で動的に変更可能なLexer & parser作るのも大変だなぁ。
有り物でどっかないかな……
ということで質問しました。