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

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

[前50を表示]
250:デフォルトの名無しさん
09/07/09 10:16:58
母国語でおｋ

251:デフォルトの名無しさん
09/07/09 16:11:15
アセンブラどころかリンカもローダも自作したが
最初は使えるものを使って、徐々に置き換えていけばいいんじゃない

252:デフォルトの名無しさん
09/07/21 23:01:50
Richard Bornatのコンパイラの本でお勧めですか？

253:デフォルトの名無しさん
09/07/21 23:26:02
日本語でおｋ

254:デフォルトの名無しさん
09/07/24 21:58:11
やさしいコンパイラ（デコイ本）はやめたほうがいい
ふつうの方は神本確定の出来だった

255:デフォルトの名無しさん
09/07/25 00:56:59
やさしいコンパイラ貶して
ふつうの方宣伝してる人は
まったく具体的な指摘がないんだよな

256:デフォルトの名無しさん
09/07/25 01:09:34
と、ここぞとばかりに架空の傾向を持ち出すわけですね。

257:デフォルトの名無しさん
09/07/25 09:32:51
ふつうのコンパイラ良書なんでしょうか
学生なのでちょっと資金余裕がなくて

258:デフォルトの名無しさん
09/07/25 09:38:48
研究室で買ってもらえばいい。あるいは図書館。

259:デフォルトの名無しさん
09/07/26 02:01:07
mingw-jpの使い方まったくわからないので
どなたか教えてもらいたいのですが

260:デフォルトの名無しさん
09/07/26 17:17:33
言語ワークベンチは究極的には完全にプログラミング方法を変えるかもしれない
URLﾘﾝｸ(www.infoq.com)

261:デフォルトの名無しさん
09/07/26 17:40:02
>>260 なんかスタイルシートが効いてなくて生々しいレイアウトになってない？

262:デフォルトの名無しさん
09/07/26 17:57:19
>>261
今見たが、特に問題ないぞ。

263:デフォルトの名無しさん
09/07/27 11:25:26
>>261
うちの環境だとこうなってる
IE6　ちゃんと出る
FireFox　スタイルシートが効かない
Google Chrome　スタイルシートが効かない上に画像も表示されない

264:263
09/07/27 11:30:13
今見たら直ってました。

265:261
09/07/27 12:19:46
うーん。うちのFirefoxだと変わらずだな。
エラーコンソールになんか出てるけど、それが原因を示してるのかわからん...

266:デフォルトの名無しさん
09/07/27 13:05:55
>>265
リロードしたらＯＫになったよ、うちのFX

267:デフォルトの名無しさん
09/07/27 14:00:29
うちもFirefoxだと一度目はスタイルシート読み込まれないな
まぁスレには関係ない話題だが

268:デフォルトの名無しさん
09/07/28 14:39:17
>>260
どっちかというと設計よりの話だね。

269:デフォルトの名無しさん
09/08/01 04:41:50
.NET周りで使えるもの、という条件だが。
・Lexical analyzer and parser generator

単純だがよくできている。構文木を食わせてソースコードを吐かせるBison式。
最初これで作りかけていたが、パーサーを構築できてもそのパーサーが予定の挙動をしない場合、デバッグの方法が困難。
（テーブルに分解されてしまうため、ソースが追いかけられない）
パーサーの動作は高速と思われる。

・Irony
パース、構文木構築までをやってくれるコンパイラを動的に構築してくれる。
簡単なGUIのパーサーチェッカーが付いていて、開発がかなり楽
（すごい楽かはもっと楽なものがあるのかどうか知らないので……）
動的に構築する分lapgより遅いかもしれないが、とりあえず自分の目的にはこれで十分なので。

ただ、コンパイル済みコードを吐かすために自分用の構文木を
もう一度作り直す羽目になるのは激しくビミョー……。
（別にそのまま構文木を消化していったっていいわけだが。
　まあ少なくともテキスト形式で出力するにはあの構文木のオブジェクト構造は向いてないな）

270:デフォルトの名無しさん
09/08/01 04:55:36
修正と補足。
「構文木を食わせて～」は、「BNF定義を食わせて～」が正しい。
lapgもIronyもどちらもEBNFではなくBNF式。（Wikipediaで調べた限りでは）
ただしどちらもパースに正規表現が使える。

lapgは非Ascii文字の正規表現パースがどうも挙動が怪しい……。
Ironyはホワイトスペースの除去以外にも非構文要素を取り除けるチャンスがあるので小回りが効くようだ。
(といったところも気に入っている)

271:デフォルトの名無しさん
09/08/01 13:51:44
JetBrains Meta Programming System
これが最強他は全て旧世代の糞技術

272:デフォルトの名無しさん
09/08/01 14:25:38
>>271
どんなものか説明してみれ

273:デフォルトの名無しさん
09/08/01 14:32:14
.NET向けの旧来のスタイルのものとしてはGPPG/GPLEXが定番
GPPGはIronRubyにも使われてる

274:デフォルトの名無しさん
09/08/01 15:05:06
ドラゴンブック買ってきたぞ！さあ読むぞ！

275:デフォルトの名無しさん
09/08/01 16:48:45
>>273
なるほど……。
現在はMPPG/MPLEXと名前が変わってるようだけどね。

どうせいずれVisual Studioの胸を借りる（SDKを使ってオレ様IDEを作る）予定なので、
はじめからこちらで構文解析を実装しておいた方が
構文の強調、InteliSenceなどで使い回しが利くかもしれない。

結構進んでてあとはエラー周りくらいだったんだが、破棄してしまうかなぁ……。

276:デフォルトの名無しさん
09/08/01 16:55:06
MPPG/MPLEXはまた別物だよ(MSがVisual Studio SDK用にカスタマイズしたもの?)
本家はURLﾘﾝｸ(plas.fit.qut.edu.au)で開発継続中でドキュメントも充実してる

277:デフォルトの名無しさん
09/08/01 17:30:29
>>276
HPみてみたら、GPPG is closely related to the “Managed Package Parser Generator” application
って書いてるね。

今仕様を決めているスクリプトは文法がPythonに似ているので
IronPythonがどうなってるか調べてみたら、こっちはパーサーを自前で書いてる……？
（ソースコード中に直接コメントでBNFが書いてある）

278:デフォルトの名無しさん
09/08/01 17:42:08
ともあれ、BNF定義の中に直接コード片が埋め込めるGPPG/MPPGの仕様は興味深いね。
ただそれだけに、PDFドキュメントだけじゃなくて実際に動くサンプルプロジェクトが欲しいところだなぁ。
どっかにお手ごろなのが落ちてないかな。

279:デフォルトの名無しさん
09/08/01 18:06:36
>>276のサイトにあるパッケージには電卓のサンプルが付いてる。
言語なら
URLﾘﾝｸ(www.iunknown.com)
これなんか手ごろで面白い。あとは大規模だけどIronSchemeやIronRubyくらいかな。

280:デフォルトの名無しさん
09/08/01 18:20:30
>>278
> ともあれ、BNF定義の中に直接コード片が埋め込めるGPPG/MPPGの仕様は興味深いね。

>>276のサイトも見ないで聞くがyaccなんかのアクションとは違うもの？

281:デフォルトの名無しさん
09/08/01 18:41:28
同じです
言語定義が処理系を実装する言語に依存しないというのは，むしろ流行りの売り文句です

282:デフォルトの名無しさん
09/08/01 18:47:36
>>281
> 同じです

じゃあ>>278は何が興味深いんだろうか？

> 言語定義が処理系を実装する言語に依存しないというのは，むしろ流行りの売り文句です

JavaでいうとSableCC的なやつかな
JavaCC+JJTree、ANTLRでもできるが

283:デフォルトの名無しさん
09/08/01 19:06:25
> GPGP is a generator for LALR(1) parsers. It accepts a
> “YACC/BISON-like” input specification and produces a C# output
> file. The parsers that it produces are thread-safe, with all parser
> state held within the parser instance.

プログラミング言語非依存でもないよ。

284:デフォルトの名無しさん
09/08/01 19:09:44
>>280,281
278だが、その点で言えば、269で挙げたLexical analyzer and parser generatorはC++/Java/C#形式で吐き出せるよ。
だがこちらとしては、実装言語の非依存性などどうでもよい。
パーサーを実装しやすい仕様になっていればそれでいいわけ。

実装しやすさという観点で言えば、BNF式ごとにコードが埋め込めるGPPGは小回りが利きそうだし、
コンパイラやエラー処理があらかじめ一通り実装された状態で使えるIronyよさげ、というわけで。

285:デフォルトの名無しさん
09/08/01 19:14:10
>>284
話の流れが見えてなくてすまないが、要は昔ながらのコンパイラ・コンパイラが
欲しくてGPPGがそうだってだけ？
仕様が興味深いというから何か目新しいネタがあるのかと期待しちゃったんだが

286:デフォルトの名無しさん
09/08/01 19:16:39
ANTLRみたいなのって，C#にも対応してるよと謳ってるのが多いけど
ランタイムの実装が糞すぎて使い物にならないのが多いんだよね

287:デフォルトの名無しさん
09/08/01 19:28:14
>>286
学者風情が作った糞ライブラリに
期待するなよｗ自作しろ

288:デフォルトの名無しさん
09/08/01 19:37:36
>>284 >>286 >>287
ノイズレスはやめてくれ

289:デフォルトの名無しさん
09/08/01 19:47:26
>>285
他のやつらとこのスレの趣旨的にはどうか分からないが、
オレとしては自分で仕様を決めたスクリプトを他の形式にコンパイルするのに
必要十分な環境をそろえられればいい。

GPPG(MPPG)はスレの流れからするとyaccに仕様が近いようだが、（いわゆる昔ながらのコンパイラ・コンパイラ）
別にそれにこだわりはない。
むしろIronyによる作りやすさを評価してるくらいだ。
ともあれ、構文木を作った後が大変なんだがな……。

290:デフォルトの名無しさん
09/08/01 21:50:56
確かに、はじめてyaccを知ったときは大変興味深かった。

>289はGPPG？で今その感動を味わっているわけだ。

291:デフォルトの名無しさん
09/08/01 21:55:08
>>289
あんなバグフィックスも含めて、
ちゃんとメインテナンスされてるどうかわからんツールよく使えるな。
近況はブログにでも書いてて欲しい。

292:デフォルトの名無しさん
09/08/01 22:02:23
>>291
リリース版しか見てないだろ。
Subversionのリポジトリみたら今月に至るまでコミットされつづけてるぞ。
というか、作者に連絡して修正パッチを投げてさっき返事が来たところだ。

codeplexにおけるプロジェクトratingsも★5つだし、どこが気に入らないのか知らないが、
まあオレが使いこなせれば済むことだからいいや。

293:デフォルトの名無しさん
09/08/01 22:27:30
yaccを知らずに僕らは生まれた～
lexを知らずに僕らは育った～

294:デフォルトの名無しさん
09/08/02 10:06:57
PEG世代の歌か？

295:デフォルトの名無しさん
09/08/03 00:01:46
夏休みなんで
C++でPEGかpackratのパーサ作ってみたいのですが
何を参考に作るのが面白いでしょうか？

296:デフォルトの名無しさん
09/08/03 00:13:52
ポリエチレングリコール？
いやいや・・

297:デフォルトの名無しさん
09/08/03 00:23:12
>>295
PEGは新しい概念で古い言語向けにはあまり実装されて無いんじゃね？
Haskell、Pythonあたりを使うことをお勧めする。

298:デフォルトの名無しさん
09/08/03 11:42:07
URLﾘﾝｸ(pdos.csail.mit.edu)
Packrat の総本山に、C++ 実装へのリンクがいくつかあるよね。

299:デフォルトの名無しさん
09/08/03 12:00:32
PEGって使いやすいの？
CFGに比べた利点・欠点とか
こういうのが書きやすいとか書きづらいとかありますか。

300:デフォルトの名無しさん
09/08/03 12:29:13
原理的には、バックトラックのあるトップダウンパーザの受け入れる文法そのもの
なので、CFGに比べて、原理を理解してしまえば直感的。

利点とも欠点ともとれるけど、レキシカルアナライザと統合される。

ナイーブな（メモ化なし）実装だと、指数的に時間がかかり、かつ無駄が多い。

301:デフォルトの名無しさん
09/08/03 12:41:16
C#の処理系ってことでIronMetaを眺めてみたが、こりゃあ異次元行ってるな。
ぱっと見ただけじゃさっぱりわからんぞ……。

302:デフォルトの名無しさん
09/08/03 12:56:06
? これ別にC#をパースしてるわけじゃないと思うよ
yaccみたいにテキスト的に処理してるだけだろ

303:デフォルトの名無しさん
09/08/03 12:58:29
>>302
まあそうなんだけど、C#自体の文法と似通っていて、
どこまでがC#の文法なのかが非常にわかりにくい。

どう見ても構文の宣言とラムダ式の定義が混じって見える。

304:デフォルトの名無しさん
09/08/04 01:55:34
>>303
そもそもそういう人が処理系なんて書けるの?

305:デフォルトの名無しさん
09/08/04 07:32:04
>>304
んんー、昨日いっぱいまでで、Irony使って大体書き上げてしまったぞ。
単独ファイルのコンパイルは文法の厳密化とか以外は大体こんなもの。
あとはエラー出力を整理してGUIくっつけて複数ファイルのコンパイルに対応したらおしまい。

ソースコード吐き出し式よりライブラリ式の方がオレには使いやすいようだ。

306:デフォルトの名無しさん
09/08/04 10:55:30
C#って文法は単純でも中身は超複雑だぞw

307:デフォルトの名無しさん
09/08/04 12:43:57
中身w

308:デフォルトの名無しさん
09/08/04 16:08:03
PEGのパーザジェネレータ作るのはかなり簡単だよ。LL(1)やLALR(1)のパーザジェネレータ
作るのと比べてもかなり簡単。LLやLR系だと文法に対するグローバルな解析が必要になるけど
PEGはそういうのしなくていいし。パーザジェネレータじゃなくてパーザコンビネータならもっと簡単に書ける
無名関数に相当する機能がある言語だったら、大体100行程度で基本的な機能を持ったものを作れる

309:デフォルトの名無しさん
09/08/04 16:14:10
PEGの利点：
・原理的にyaccとかのLALR(1)より強力なので、yaccでハンドリングするのが難しい文法も簡単に扱える(ことがある)
・レクサとパーザが統合されてるので、Rubyの"#{exp}"みたいな式埋め込み文字列みたいな文法も簡単に扱える
　・Rubyとかではトリッキーな事をしてこの問題を回避している
・アルゴリズムが簡単なので挙動を理解しやすい＝文法をデバッグしやすい（かも）

PEGの欠点：
・ナイーブな実装では最悪の場合指数関数時間（だけど、実用上最悪ケースはそんなに起きないと思う）
・メモ化(Packrat)しても、定数係数でLLやLRとかの非バックトラック型のパーザよりは遅い
・Packratだと、状態付きパーザを扱うのが難しい(シンボル表を参照しながらパーズする場合など)
・レクサとパーザが統合されてるので、空白とかの処理がやや面倒

310:デフォルトの名無しさん
09/08/04 16:14:12
それはPackratパーザ？
それともバックトラック？

311:デフォルトの名無しさん
09/08/04 16:15:27
>>310
Packratも基本的には、単にナイーブなPEGパーザをメモ化するだけなので、多少手間が増えるくらいで、実装は難しくは無い

312:デフォルトの名無しさん
09/08/04 16:28:07
とりあえずLISP系でスマートに実装してみて！
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

313:デフォルトの名無しさん
09/08/04 16:43:41
>>312
OK. 1時間くらい待っててくれ

314:デフォルトの名無しさん
09/08/04 16:50:54
なんかPEG/Packrat詳しい人がいるみたいなので質問させてくれ。
手元のPEGのサンプルは四則計算を解釈していて、いきなりインタプリタとして動くようになっている。
いきなり動かすんじゃなくて構文木構築の段階で動作をとめることはできるんだろうか？

それから途中まで解析した文脈を情報として続く解釈で再利用できるだろうか？
例えばPythonの文法を考えてもらうとして、

# ***ここから***
if [Expr]:
　　[Sentence]
　　[Sentence]

[Sentence]
# ***ここまで***

Pythonでは構文の範囲は字下げで表現しているので、
if文の範囲を調べるのに字下げの数を数えないといけない。
どうやって解釈させたらいいのかわからなくて戸惑っているところなんだが。

315:デフォルトの名無しさん
09/08/04 17:21:20
そのサンプルは、構文木を作ってから四則演算を実行してるんじゃなくて、
いきなり構文を解析しながら四則演算をしてるんじゃなかろうかという気がするが。

オフサイドルールとかはPEGの鬼門だということかと。
確か原論文では、それを理由にHaskellはムズいとして、Javaのパーザを
実装していた。
多分さがせば解決方法が出てる論文もあるだろうと思うのだけど。

パーザを状態付きにする方法は原論文にある。

316:デフォルトの名無しさん
09/08/04 17:56:21
>>309
> 定数係数で

この言葉遣いはちょっと変なのでは?

>>314

字下げ処理はレキサの仕事と割りきってしまえばそれほど難しくはないでしょ。
先読みして{と}に相当するものに変換できるから。

317:313
09/08/04 18:20:40
(use srfi-9)
(define-record-type result
　(make-result x y) result? (x value) (y next))
(define (app parser f)
　(lambda(in)
　　(define r (parser in))
　　(if r (make-result (f (value r)) (next r)) #f)))
(define (term str)
(lambda(in)
(if (equal? (string-scan in str ' index) 0)
(make-result str (substring in (string-length str) (string-length in))) #f)))
(define (/: x y) (lambda(in) (or (x in) (y in))))
(define (^: x y)
　(lambda(in)
　　(define r1 (x in))
　　(if r1
　　　(let ((r2 (y (next r1))))
　　　　(if r2 (make-result (cons (value r1) (value r2)) (next r2)) #f))
　　　#f)))
(define (seq p . parsers) (fold (lambda(x y) (^: y x)) p parsers))
(define (rep0 parser)
　(lambda(in)
　　(let loop ((rest in) (rs '()))
　　　(define r (parser rest))
　　　(if r (loop (next r) (cons (value r) rs)) (make-result (reverse rs) rest)))))
(define (rep1 parser) (^: parser (rep0 parser)))
(define (? parser) (/: parser (app (term "") (lambda(v) '()))))
(define (& parser) (! (! parser)))
(define (! parser) (lambda(in) (if (parser in) #f (make-result '() in))))
(define-syntax rule
　(syntax-rules() ((_ name body) (define name (lambda(in) (body in))))))

318:313
09/08/04 18:25:10
なんとか１レスの範囲に収めたが、そのせいもあって、読みづらくなってる。その辺は読む側
の環境で適当になんとかしてくれ。あと、Gaucheのライブラリ関数string-scan使ったので、Gauche
でしか動かんと思う。string-indexとかに置き換えれば、他のSchemeでもたぶん動くと思われ。
Schemeは普段使わないんで、Scheme使いの人からするとアレなコードかもしれんが、そのへんは勘弁。
使い方は以下のような感じ。文脈自由文法では表現できない、A^n B^n C^nの文法。

(rule S (seq (& (^: A (! (term "b")))) (rep1 (term "a")) B (! (term "c"))))
(rule A (seq (term "a") (? A) (term "b")))
(rule B (seq (term "b") (? B) (term "c")))
(display (S "aaabbbccc"))

319:313
09/08/04 18:28:52
Pythonのインデントルールみたいなのは、レキサがインデント処理する事が前提だから、PEG/Packrat
で処理する場合でも、レキサを別に用意した方が書きやすいと思う。レキサがあったらPEGじゃないというわけ
じゃないので別に構わないはず(基本単位が文字の代わりにトークンになるだけ)。

320:デフォルトの名無しさん
09/08/04 19:26:20
>313
うお、本当にできてる！
たしかにこれはクロージャ使えない言語では無理だ
こういう風になったけど合ってますか？

gosh> (display (S "aaabbbccc"))
#<result 0pbb1788>#<undef>

gosh> (define res (S "aaabbbccc"))
res
gosh> (result? res)
#t
gosh> (value res)
(((() #0="a" #0# #0#) (#1="b" (#1# (#1#) . #2="c") . #2#) . #2#))
gosh> (next res)
""

321:313
09/08/04 19:34:21
>>320
たぶんそれであってる。まあ、これだけだと構文エラー時のエラーメッセージ
表示とかどうしようも無いし、実用的にしようと思うと、色々付け足す必要があるけど、
コアの部分はこれくらい簡単だということで。

322:デフォルトの名無しさん
09/08/04 23:05:50
みんな論文みながら作ってるの？
どうやってpackrat実装すればいいかよくわからん

323:デフォルトの名無しさん
09/08/04 23:21:12
21世紀…人類はいまだに左再帰問題を克服できずにいた

324:313
09/08/05 00:55:09
>>322
一応、自分が作ったときは論文参考にしたけど、基本的にナイーブなPEGパーザ＋メモ化に過ぎ無いから
それさえわかっていれば、自力で実装することもできると想う。ヒントとして、上で書いたSchemeによる
パーザコンビネータで、各非終端記号の解析結果をメモ化するにはどうすればいいか考えてみて。
Rats!とか高度な最適化してる奴はまあソース読むしかないと思うけど。

325:デフォルトの名無しさん
09/08/05 01:16:54
左再帰の論文もあったような。

326:デフォルトの名無しさん
09/08/05 02:07:47
これのことかな。
Packrat Parsers Can Support Left Recursion (PEPM 2008)
Alessandro Warth, James R. Douglass, and Todd Millstein
URLﾘﾝｸ(www.tinlizzie.org)

327:デフォルトの名無しさん
09/08/08 18:40:53
COBOLインタープリタを作ろうと思ったが挫折。
制定されているキーワードの数が尋常じゃない。
商用COBOLコンパイラを作っているメーカーの人はマジ天才。

328:デフォルトの名無しさん
09/08/08 19:51:58
何でそんなものを作ろうと思ったんだｗ

329:デフォルトの名無しさん
09/08/09 03:42:55
COBOLかっこいいじゃん。大文字で。
Cを使える人はいっぱいいるけど、COBOLはそうはいない。
だからこっそり開発して職場のヒーローになろうと思ってね。
でも道は遠かった・・・使うのと作るのとは別物なのだ。

330:デフォルトの名無しさん
09/08/09 09:26:31
>>327
> 制定されているキーワードの数が尋常じゃない。
何のためにパーサジェネレータがあるんだか
まあ、BNF 打ち込むだけで疲労困憊ってのはあるかもしれんが…

331:デフォルトの名無しさん
09/08/09 09:32:18
大文字使いたいだけならマクロでも使えばいいじゃん

332:デフォルトの名無しさん
09/08/09 10:31:58
>>330
やっぱ疲労困憊ら？(静岡弁で)

333:デフォルトの名無しさん
09/08/09 11:53:19
>COBOL
ほとんどは命令の名前なんだから、Identificationのレベルで区切って、
命令の判別はあとの段階にまわした方が簡単になるんじゃない？
あとはまあ、フリーソフトのCOBOLの処理系なんて昔ならともかく今ならいくつもあるんだし、作らないという手も。

334:デフォルトの名無しさん
09/08/12 15:03:20
ゲームのNPCとかにスクリプトを使いたいんだけど
参考になるサイト教えて、lexとかyaccとか難しいのはいらない

335:デフォルトの名無しさん
09/08/12 15:32:59
>>334
とっつきは悪いかもしれないけど、yacc&lexを使った方が
結局は落だと思うよ。

336:デフォルトの名無しさん
09/08/12 16:35:21
>>334
オープンソースのスクリプトの処理系を組み込んだ方が普通は楽。
オレはそれにシナリオ記述用の独自形式のスクリプトと２種類用意しているが。

337:デフォルトの名無しさん
09/08/12 17:11:04
>>334
ゲームの性質（リアルタイムとかアドベンチャーとか）にもよるけど
ゼロから勉強しなきゃいけないならYaccとかbisonとかの支援受けるのは悪くないと思うよ
組み込みでスクリプトをその場解析する必要があるならLRのパーサを裸で実装したマイクロPlan（1970年代のbitの記事）とかもあるからそういうレガシーなものもいいかもしれない（これは中間コードＶＭとしても結構興味深い）

っというわけで334がどういうものを欲しているかによって回答が異なるのだな

338:デフォルトの名無しさん
09/08/12 21:00:13
luaは洋ゲーで良く使われてる

339:デフォルトの名無しさん
09/08/12 21:21:39
>>337
マイクロPlan懐かしすぎ
臨時増刊捨てなきゃよかった

340:デフォルトの名無しさん
09/08/12 23:00:14
>>339
同じく後悔してる
他にもmicro StarTrekやTinyBASICのソースもあったんだよな

>>334
ゼロから勉強するつもりで、もし入手できるなら「翻訳系構成法序論」がお勧め。
えらく堅苦しい題名だけど、たった136ページで翻訳系(コンパイラ)から
翻訳器生成系(yaccのようなコンパイラコンパイラ)まで作成方法が解説してある。
言語はPascal系なModula-2だけど、難解なアルゴリズムではないから、
C/Javaなどに慣れていれば読解に問題はないと思う。

あと、自前で言語処理系を作らないつもりなら、Tcl/Ruby/Pytonみたいな
汎用スクリプト言語をゲームアプリの中に「埋め込む」ことも検討できる。
ゲーム専用のスクリプトエンジンについては、よく分からんなぁ。

341:デフォルトの名無しさん
09/08/13 01:44:52
老婆心だが、Tcl/Ruby/Python のうち、Rubyを組み込むのは
やめたほうがいいと忠告しておこう

Tclはもともと組み込みのための処理系だし、Pythonもある程度
考えてあって商用も含めて実績も多い。

R（以下略

342:デフォルトの名無しさん
09/08/13 01:51:34
PL/0まじおすすめ
許されるのは小学生までだけど

343:デフォルトの名無しさん
09/08/13 01:59:01
>>334
tclかluaを使うことにして、公式ドキュメントを。

344:デフォルトの名無しさん
09/08/13 02:48:09
>>334
あとはまあ、NPCの台詞や動き程度なら、
イベントの発生条件とイベントの内容をデータとして書ければいいわけだから、
スクリプト言語を使うまでもなく、
XMLやYAMLなどで宣言的データとして書く方法もある。

ちょうど、同じようなものを自分で作ろうとしているところ。

345:デフォルトの名無しさん
09/08/13 03:15:15
>>341
スレ違いの質問で悪いが、続きを聞かせてくれ。

実際、Pythonを組み込んだオプソだけど高機能な3Dソフトを
知っているし、それに対してRubyはvimくらいしか実績を知らない。
ただ、Rubyの組み込みに何か技術的に致命的な欠陥があったりするのか、
あるいは、それほどPythonが組み込みに優れているのかまでは分からないんだ。
それとも単に>>341の印象で語ってるのか？

346:デフォルトの名無しさん
09/08/13 03:35:11
>>345
341ではないが、代わりに答えてみよう。

Rubyでは処理系そのものをライブラリの形で差し替えたり、
あるいはJavaや.NETの枠組みで処理系そのものを再実装したりの試みは広く行われているが、
Rubyを組み込みスクリプトとして使用する例はオレもRPGツクールXPくらいしかしらない。
あまりその辺の分野は活発ではないような気がする。

いい加減スレ違いだから、これ以上の話はRubyのスレに行ってくれ。

347:デフォルトの名無しさん
09/08/13 10:55:31
独自に実装かつ、yacc&lexは難しいと言うなら、LISPかForthがいいんじゃね？
LISPはよく見るから、あえてForthでやってみてくれ。

348:デフォルトの名無しさん
09/08/13 13:30:18
>>345
ruby は GC というかメモリ管理まわりの兼ね合いで
組み込みがかなり面倒、という話を聞いたことがある

349:デフォルトの名無しさん
09/08/13 14:10:04
スレチだけど、言語実装の話でもあるので、ちょっとRubyの話を続けると、
組み込みに向かないのは、evalがあるのが大きいと思う。
そのせいで、パーサとVMが独立できないので、言語まるごと組み込む必要が
あるのが大変なんじゃないかと。
1.9でその辺は変わったみたいだけど。

350:デフォルトの名無しさん
09/08/13 14:27:07
行の1文字目で処理を分ける程度でいいんじゃね？

351:デフォルトの名無しさん
09/08/13 14:33:22
１文字で思い出したけど、変数名が１文字の場合はハッシュ使わないで
２６個のテーブルってのどう？

352:デフォルトの名無しさん
09/08/13 14:41:29
いつの時代のＢＡＳＩＣだよ

353:デフォルトの名無しさん
09/08/13 15:08:53
Rubyの話をもちっと聞かせてくれ。
俺も拡張機能用にPythonを組み込んだアプリは良く見るが
Rubyを組み込んだアプリは見たことが無い。
これは単にRubyが歴史が浅いからなのか、それともRubyが組み込みで使えない深い理由があるのか？

354:デフォルトの名無しさん
09/08/13 15:33:13
>>352
難読化したjQueryとかじゃね？

355:デフォルトの名無しさん
09/08/13 16:00:40
じゃあこのスレっぽく話を広げようか
俺341だけど、言いだしっぺっぽいので

まず指摘されてたけど、メモリ管理の点で、1.8時代はネイティブスレッドとは
破滅的に相性が悪かったし、ウィンドウシステム・３D・DirexX関係も
相性はあまりよくない。

それに対してPythonは参照カウントとマーク＆スイープの組み合わせで、
マーク＆スイープもおとなしいタイプ。
参照カウントってのはちょっとダサいが、質実剛健だしその点では好感。

あと、これは俺の想像だけど、Pythonの作者は、PythonからCを使うってのと
CからPythonを使うってのを対称的で対等なものとして考えている雰囲気があるし、
技術的に変なこだわりはなくて、いろんなところに配慮しながら無難な実装をしてる。

Rubyは実装技術オタクのMatzが作ったので、変なところでこだわってたり
無駄に離れ業やってたりしてタチが悪い
ただし、Rubyは将来的にはマルチVMも可能にしようという方向で動いてるようだから
そこらへんは変わってくるかもしれない

356:デフォルトの名無しさん
09/08/13 20:56:15
とりあえず Google SketchUp が Ruby 組み込みだったはず。

357:デフォルトの名無しさん
09/08/14 01:20:18

Q. 64bitプログラムとは、どのような文を書くといいのですか

A. コンパイラが64bitコンパイルできるなら何でも64bitプログラムになります

心底「ダメだこのバカ」と思った

358:デフォルトの名無しさん
09/08/14 09:35:58
>>357
つぶやきはtwitterで

359:デフォルトの名無しさん
09/08/14 11:41:34
>>357
スレ違い

64bitのソフトウェアってどうやって作るの？
ｽﾚﾘﾝｸ(tech板)

そのセリフの人物によっては

ハズレの外注を引いたときの対応 2人目
ｽﾚﾘﾝｸ(prog板)
【まるで】使えない新人 0x1C
ｽﾚﾘﾝｸ(prog板)

など

360:デフォルトの名無しさん
09/08/14 21:52:07
トークンという物について質問させてください。
例えば s = "ABC"; という文があった場合トークンは、
1. s
2. =
3. "
4. ABC
5. "
6. ;
でいいのでしょうか？とくに文字列が "ABC" で1つのトークンなのか
"とABCと"で3つのトークンなのかがわかりません。

361:デフォルトの名無しさん
09/08/14 21:59:32
s
=
"ABC"
;
と分けるのが一般的かと思います

362:デフォルトの名無しさん
09/08/15 00:06:09
Forthは"が単独トークンになるね。

363:345
09/08/15 00:07:23
スクリプトエンジンのスレだから、
「組み込み用途における技術的観点での比較」に絞ってレスする。
宗教戦争を煽る気はない。

>>346
>あまりその辺の分野は活発ではないような気がする。

Rubyは組み込みの実績が少ないし活動が活発ではないという理由かな。
それは技術的な理由からは外れている気がする。そうなった理由(背景)がこのスレの主題。

>>349
>そのせいで、パーサとVMが独立できないので、言語まるごと組み込む必要が
>あるのが大変なんじゃないかと。

Rubyが言語まるごと(パーザ+VM)組み込む必要があるのは事実。
ただし、個人的な感覚として、アプリケーションにスクリプトを組み込む目的の多くは、
ユーザによるアプリケーション機能の自由な拡張(スクリプティング)なのだから、
まるごと実装は欠点にはならないと思う。(JavaVMのようなコンパイラ系は別)

(長いので続く)

364:345
09/08/15 00:10:47
(>>363の続き)

>>355
>まず指摘されてたけど、メモリ管理の点で、1.8時代はネイティブスレッドとは
>破滅的に相性が悪かったし、

Rubyとネイティブスレッドとの破滅的な相性の悪さは事実なので同意。
ただし、多くのアプリケーションでは、ネイティブスレッドが前提とはならない
(あるいはRubyの疑似スレッドでもかまわない)ケースが大半を占めるのではないかと思う。

>ウィンドウシステム・３D・DirexX関係も相性はあまりよくない。

RubyもGNOME, WxWidget, Qt, Cocoa, SDLとウィンドウ(GUI toolkit)は揃っているし、
3DもOpenGL拡張ライブラリがあるから、相性が悪い理由にはならない。
DirectXは(おそらく)Rubyで対応しておらず、Phytonの実績が多いのかも(?)しれないが、
それは実績が多いという事実の言明だけであって、具体的な技術面の指摘ではない。
そもそも、これらは拡張ライブラリであってエンジン組み込みではないからスレ違い。

>それに対してPythonは参照カウントとマーク＆スイープの組み合わせで、
>マーク＆スイープもおとなしいタイプ。

GC制御に関わる所有ルールの難解さは、RubyにもPythonにも同様に存在する。
またGC方式の差異は、組み込み用途の利点とは直接的に結びつかないのでスレ違い。
(もし関連性があると考えているなら、具体的に差異を説明してください)

>あと、これは俺の想像だけど、Pythonの作者は、PythonからCを使うってのと
>CからPythonを使うってのを対称的で対等なものとして考えている雰囲気があるし、

対称性はRubyも変わらない。実装の難易度も同等というのが、個人的な実感。

(まだ続く)

365:345
09/08/15 00:15:27
(>>364の続き)

>技術的に変なこだわりはなくて、いろんなところに配慮しながら無難な実装をしてる。

これは(スレ違いだけど)同感で、PythonがSimple is bestを追求してるのは好感。ただし、

>Rubyは実装技術オタクのMatzが作ったので、変なところでこだわってたり
>無駄に離れ業やってたりしてタチが悪い

については、組み込み用途とは無関係だし、Rubyがスキャナとパーザの実装で
離れ業をしている事を除けば、具体性の無いMatzへの個人批判でしかないのでスレ違い。

以上、個人の印象/主観を除いたRubyの組み込み用途における技術的な問題点をまとめると、

- 言語まるごと(パーザ+VM)組み込む必要がある
- ネイティブスレッドとの破滅的な相性の悪さ

の二点のみ。組み込み用途に限れば、Pythonと比較した決定的な欠陥は見当たらない。
実際、拡張ライブラリ(Ruby->C呼び出し)を自作できるRubyプログラマであれば、
Ruby組み込み(C->Ruby呼び出し)も難儀な実装作業ではない、というのが個人的な実感。
(PythpnでもPython->C呼び出しが実装できない人であれば(その逆の)組み込みが難しいのは同じ)

(ゴメン、次で最後だから許して)

366:345
09/08/15 00:18:02
(>>365の続き)

あと(技術的な観点ではないけど)付け加えるとすれば、
Pythonは公式文書として組み込み方法が解説されているのに対して、
Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が
唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差異が、
組み込み実績という結果に大きく影響していると思われる。

これだけだと何の事か分かりずらいと思うので、最後に具体的なアドバイスをまとめる。

- RubyプログラマはRuby組み込みで、PythonプログラマはPython組み込みを選ぶのが楽
- ただし、ネイティブスレッドが前提なアプリケーションであれば、Pythonしかない
- どちらも知らない人は、(解説文書が整備されている)Phyton組み込みが無難な選択(=お勧め)
- ただし、言語の選択は、システム全体を見渡してから判断すべき(解説文書の有無だけで
　言語を選択すると、本末転倒になる恐れがある(木を見て森を見ず))

長文/連投のスレ汚し、失礼しますた。

367:デフォルトの名無しさん
09/08/15 00:43:35
元々の話のゲームのスクリプト用途とかなら
既に挙げられてはいるけど lua みたいな
最初から組み込み用に作られたものを使うのが無難じゃないかな
変に難しいこと考えなくても楽に組み込めるし

368:デフォルトの名無しさん
09/08/15 00:53:25
長過ぎて読んでないが、
結局Rubyを無理やり組み込む人はいないと

369:デフォルトの名無しさん
09/08/15 00:53:49
これだけ長文でレスしたくせに、中身がほとんど無いじゃないか。
スレ違いをいちいち長ったらしく指摘しなくていいからもっと短くまとめろよ。

> あと(技術的な観点ではないけど)付け加えるとすれば、
> Pythonは公式文書として組み込み方法が解説されているのに対して、
> Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が
> 唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差
> 異が、組み込み実績という結果に大きく影響していると思われる。

付け加えじゃなくて、ここが一番重要なところだろ。

370:デフォルトの名無しさん
09/08/15 00:58:42
機能的にはschemeやjavascript辺りのサブセットがVMで動けば十分
バランスが取れたのがlua
実際にスクリプトを書かせる対象を想定しないとな

371:デフォルトの名無しさん
09/08/15 01:04:13
>>366
まず、俺の主観が入っているってのはその通り。その点はすんまそん
てかあまり深く考えずに書き込んだけど、363氏の説明の方がほとんど
正しいと思います。

いくつか書きたいのは、

PythonのGCは停止時間（いわゆるレスポンス）が悪くない。
循環参照を解消するために定期的に
マーク＆スイープする必要があるけど、そのタイミングは制御できる。
たとえばゲームでいえばシーン暗転の時にやるとか。
Rubyは逆で、楽だけど大味な制御しかできない
以前に256倍網道編でarton氏がpure rubyでゲーム作ってたけど、
実際実行すると結構カクカクだった

ついでにいうとCから使ってるとファイナライザが欲しくなるが、
CPythonならスコープはずれたら解放されることが（個別実装の仕様として）
保証されるので楽。

これらが決定的な利点・欠点かどうかは状況に依存するね。もちろん

あと実装じゃなくて完全にスレチだけど、ライセンスが違うのと、
（用途によるが）配布の際にバイトコード化可能かいう点もある。

以上で撤収します

372:デフォルトの名無しさん
09/08/15 01:40:39
forthってGCってあるんだっけ？
あれ？ディクショナリ内にメモリって確保するんだっけ？

373:デフォルトの名無しさん
09/08/15 01:48:28
組み込み用スクリプトのインタプリタとライブラリのデバッグに時間を掛けたくないよね
ゲーム本体よりも大きいと本末転倒だし
ソースがせいぜい２～３ファイル、合計数百行程度、使えるライブラリは関数をテーブルに登録ぐらいが理想か

374:345
09/08/15 02:21:05
>>371
>まず、俺の主観が入っているってのはその通り。その点はすんまそん

こちらこそネチネチ書いてスマンかったです。ただ主観/印象で論議すると
宗教戦争に陥りがちだから、それを避けたかった。分かってくださいませ。

>Rubyは逆で、楽だけど大味な制御しかできない

RubyもGCを明示的に起動できますよ。シーン暗転前に起動すればいいと思いますが....。

>実際実行すると結構カクカクだった

カクカクになるのは、GCとは別の要因ではないかと思います。
GCが原因なら、(比較的あいた間隔で)実行が固まったように見えるはずですから。

>CPythonならスコープはずれたら解放されることが（個別実装の仕様として）
>保証されるので楽。

これは、(Cスタック上に)auto変数としてPythonVMを確保すれば、そのVMと実行環境が
まとめて自動的に解放されるということでしょうか？
もし本当なら、(Rubyと比較して)かなりプログラマの負担が減りますね。
あと同一プロセス上でのマルチVM(インタプリタ)も簡単に実現できると思われますし。

>あと実装じゃなくて完全にスレチだけど、ライセンスが違うのと、

Rubyライセンスは、とっても緩やかなものです。Matzは言語オタクだから、
(権利の主張よりも)自分の作品を使ってくれることに喜びを感じてるのだと想像させるほどに。

>（用途によるが）配布の際にバイトコード化可能かいう点もある。

これも、(オプソなプロジェクト以外では)採用を決めかねない大きなPythonの利点ですね。
ソース非公開というニーズは多いと思いますから、>>363の最後の段落は撤回します。

375:デフォルトの名無しさん
09/08/15 02:49:20
いまさらなんだが既存のスクリプトエンジンを組込む話は
組込み系言語スレがふさわしいと思う。

376:デフォルトの名無しさん
09/08/15 03:05:22
javascriptはBOTとかのチートツールで使われてる

377:デフォルトの名無しさん
09/08/15 03:08:01
>>375
でもあそこでpとかrとか言ったら荒れるんだよね

378:デフォルトの名無しさん
09/08/15 08:17:18
>>355
> 参照カウントってのはちょっとダサいが、質実剛健だしその点では好感。

mark & sweepと併用するやり方は、
どっちをメインにするとしても、極めて有効なやり方だよ。

379:デフォルトの名無しさん
09/08/15 09:46:27
Rubyは実装として美しくない
最近の高スペックPC当て込んだ

バブル言語だろ

380:デフォルトの名無しさん
09/08/15 10:16:03
Forthは基本的にはライブラリ（辞書）管理もFILOだから、
GCという概念がない。動的なデータ構造も（スタック以外）ないし。

PostScriptは確かスナップショットのようなものを取って、
明示的に指定してそのスナップショット以降に確保されたものを
解放するとかそういう機能がある、と思った。

381:デフォルトの名無しさん
09/08/15 11:29:43
おれ科学計算系で、3回くらいPythonが組み込まれてるソフトを
触ったことがあるよ。個人的な感想だが、pythonの微妙に面倒臭いところが、
組み込みだと逆にぴったり使いやすいんだわ。説明しづらいけど。
Rubyの自由さは組み込み向けだと正直いらない。

382:デフォルトの名無しさん
09/08/15 13:30:14
>>363-366
おおむね同意だが、>>349に対するレスはやや違うと思う。
漠然とスクリプトエンジンと題した場合、真っ先に求められるのは
書いたスクリプトをその場で実行できる手軽さであり、
必然的にインタプリタの要件を満たすことになる。
これに現在主流がバイトコンパイル式であることを勘案すると
言語まるごと(パーサ+VM)を組み込むことがほぼ確定になる。

まあオレがオレオレ処理系を作るときはスクリプトのコンパイラは
事実上のジェネレータとして実装して、
生成物は汎用のスクリプトの処理系に渡してしまうから
自作部分は純粋なコンパイラになるわけだが。

開発用にはそれとは別にスクリプトのタイムスタンプを見て
自動的にコンパイル作業を行う機能を追加することになるだろう。

383:デフォルトの名無しさん
09/08/15 13:32:25
ruby のライセンスは GPL よりは緩いけど
他の組み込み向け言語に比べると
だいぶめんどくさい方だと思うけどな
まぁライセンス云々はスレ違いだけど

384:デフォルトの名無しさん
09/08/15 13:58:23
>>382
パーサーの要不要は用途次第かと
ゲーム用とかだと開発時は素早く試行錯誤したいが
リリース後は基本的にはスクリプトをいじる必要がないので
そういう場合パーサーは無駄なので最終的には外せる方が良い
実行環境がプアなものは特に

385:デフォルトの名無しさん
09/08/15 14:58:43
これが噂の「すり合わせ」というやつか

386:デフォルトの名無しさん
09/08/15 17:01:08
生インタプリタも、中間形式分離型も両方ある奴がほしい、という
要望ってこれからも大きいかな？

今のところメジャーなもので、実現したものってないような気がするけど。

387:デフォルトの名無しさん
09/08/15 17:41:29
Ruby, Python等のダイナミック言語でパーサを分離するのは無理じゃないか？
例えばPerlだと、実行せずに静的にパースすることは不可能なわけだし。
URLﾘﾝｸ(perlmonks.org)

388:345
09/08/15 18:25:09
>>387
Pythonであれば、以下のようなカキコがあるから、
パーザとVMは分離できるように見えるけど、違うの？
Pytonにはevalは存在しないみたいだし(>>349参照)

>>371
>（用途によるが）配布の際にバイトコード化可能かいう点もある。

389:デフォルトの名無しさん
09/08/15 19:16:11
>>380
> Forthは基本的にはライブラリ（辞書）管理もFILOだから、
> GCという概念がない。動的なデータ構造も（スタック以外）ないし。

それは嘘。
FORTHを採用する場合、
後置記法を採用するくらいだから、
非常に小さいインタプリタが必要とされている局面。
だからプアな処理系が多いと言うだけで、
GCをバッチリ実装した処理系はあってもいい。

データがFILOで済むというのも嘘。
辞書に登録したら不必要になる順序はプログラム次第。

390:デフォルトの名無しさん
09/08/15 19:56:55
まあ誰もスクリプトでFORTHなんか使いたくないからどうでもいいけどなｗ

391:387
09/08/15 20:03:53
>>388
実際にPythonやRubyでパースが曖昧になるようなケースは知らないが、
evalがあると分離しにくいのは確かだろうね。ちなみにPythonにもevalはある。

392:デフォルトの名無しさん
09/08/15 21:33:03
そこれりすぷれすよ

393:デフォルトの名無しさん
09/08/15 21:35:35
Rubyが使われないのは単に実績がないからなんでしょ
どんどん使えばいいと思うよ

394:デフォルトの名無しさん
09/08/15 21:45:11
組み込みスクリプト用のLispってあるの？

395:デフォルトの名無しさん
09/08/15 21:50:20
emacs lisp

396:デフォルトの名無しさん
09/08/15 22:02:09
Ypsilon

397:デフォルトの名無しさん
09/08/15 23:35:53
elisp

398:デフォルトの名無しさん
09/08/15 23:43:00
ruby

399:デフォルトの名無しさん
09/08/16 00:05:29
>>394
小さな独自Lisp系ならいくらでもあるよ(CLとかSchemeとかの規格準拠じゃなければ8ビット機でだって動くんだもの)

400:345
09/08/16 01:27:27
>>391
え、Pythonにもevalあるんですか？！うーむ
どちらが真実かは、結局は自分で調べなさいということですな。

401:デフォルトの名無しさん
09/08/16 01:36:23
python -c 'print eval("1+1")'

402:345
09/08/16 01:52:09
>>401
再現しますた。わざわざありがトン。

403:デフォルトの名無しさん
09/08/16 02:37:35
>>394
LISPerは自分用のがあるから
他人の糞LISPなんて使わない

404:デフォルトの名無しさん
09/08/16 02:50:00
>>403
というか、そんな結論ありきな考え方をするやつなら
そもそもこんなスレに来る必要がないわけだが。

405:デフォルトの名無しさん
09/08/16 08:26:25
> データがFILOで済むというのも嘘。
> 辞書に登録したら不必要になる順序はプログラム次第。

少なくとも伝統的なFORTHなら辞書は一方向リンクトリストで最後に
登録されたものから順につながってるし、最後に登録されたワードを
グローバルなワークエリアが指している。
FORGETワードは、特定のワード以降に登録されたワードを全部捨てて
しまう。

そういう構造だから、基本的にGCはない。

406:デフォルトの名無しさん
09/08/17 10:10:39
>>394
ISLISP

407:デフォルトの名無しさん
09/08/26 22:10:05
ABAPのEBNFください

408:デフォルトの名無しさん
09/08/31 11:13:52
ANTLRで苦戦していて質問したいのですが、このスレでいいでしょうか？
もしくは専用スレを立てる？

409:デフォルトの名無しさん
09/08/31 11:40:06
このスレでいい。

410:408
09/08/31 11:58:13
お言葉に甘えて。

ng
　　: n=TOKEN (v=INT|v=FLOAT)
　　　　-> ^(PARAM $n $v)
　　;

ok
　　: n=TOKEN v=(INT|FLOAT)
　　　　-> ^(PARAM $n $v)
　　;

ngルールみたいな書き方はダメでしょうか？
antlrは通るのですが、C言語からそれを呼び出すと
セグメンテーションフォールトします。

411:408
09/08/31 11:59:43
ごめん。ngルールとokルールが逆だった。
v=(INT|FLOAT)がNGで(v=INT|V=FLOAT)がOK.
ANTLR的にv=(INT|FLOAT)という書き方はNGなのでしょうか？

412:デフォルトの名無しさん
09/09/06 21:10:45
出来ればツール頼らずに
手続き型言語作りたいんだけど
どのくらい大変なん

413:デフォルトの名無しさん
09/09/06 21:16:35
コンパイラもアセンブラもリンカもエディタもツールですよ・・・

414:デフォルトの名無しさん
09/09/06 21:40:42
Brainfuckならパンチカード手打ちしてもできるんだろうな

415:デフォルトの名無しさん
09/09/06 21:42:28
TinyBASICくらいの規模なら机上でいけるんじゃないかな

416:デフォルトの名無しさん
09/09/06 21:49:12
ツールってyaccとかlexのことか？
なくても大差ないと思うよ

417:デフォルトの名無しさん
09/09/06 21:57:54
>>412
LLで混乱しない文法なら問題ないんじゃないの？
このスレだったと思うけどμplanとかpascalの構文なら自己記述できるし

418:デフォルトの名無しさん
09/09/06 22:00:52
>>412
どういうコードに落とし込むかってあたりが問題になる位で落としやすいＶＭを設計すれば32Kワードもありゃ言語コンパイラは書ける
UCSD p-systemとかが実際そんなものだ

案ずるより産むが易しってあたりの言語なら悩む前に書き始めてみればいい
コード公開してもいいのなら行き詰まってから助けを求めに此処に戻ってこい

419:デフォルトの名無しさん
09/09/06 22:09:00
いまどきこだわることはないと思うが、
たいがいの言語ならちょいと工夫すればだいたいトップダウンパーザで書ける。

次ページ