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

1 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 20:49:02 ] プログラミング言語処理系の開発に興味のある人達のスレッドです。 字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換， CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン， SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化， JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。 意味論に関する話題も歓迎です。 過去スレ 1 pc.2ch.net/tech/kako/981/981672957.html 2 pc2.2ch.net/test/read.cgi/tech/1021136715/ 3 pc5.2ch.net/test/read.cgi/tech/1070089173/ 4 pc5.2ch.net/test/read.cgi/tech/1100097050/ 5 pc8.2ch.net/test/read.cgi/tech/1106129164/ 6 pc8.2ch.net/test/read.cgi/tech/1115335709/ 7 pc8.2ch.net/test/read.cgi/tech/1129287390/ 8 pc8.2ch.net/test/read.cgi/tech/1131273918/ 9 pc8.2ch.net/test/read.cgi/tech/1135082582/ 10 pc8.2ch.net/test/read.cgi/tech/1146844753/ 11 pc11.2ch.net/test/read.cgi/tech/1160879890/ 12 pc11.2ch.net/test/read.cgi/tech/1188688416/ 関連リンクは多分 >>2-10 あたり 303 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 12:58:29 ] >>302 まあそうなんだけど、C#自体の文法と似通っていて、 どこまでがC#の文法なのかが非常にわかりにくい。 どう見ても構文の宣言とラムダ式の定義が混じって見える。 304 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 01:55:34 ] >>303 そもそもそういう人が処理系なんて書けるの? 305 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 07:32:04 ] >>304 んんー、昨日いっぱいまでで、Irony使って大体書き上げてしまったぞ。 単独ファイルのコンパイルは文法の厳密化とか以外は大体こんなもの。 あとはエラー出力を整理してGUIくっつけて複数ファイルのコンパイルに対応したらおしまい。 ソースコード吐き出し式よりライブラリ式の方がオレには使いやすいようだ。 306 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 10:55:30 ] C#って文法は単純でも中身は超複雑だぞw 307 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 12:43:57 ] 中身w 308 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:08:03 ] PEGのパーザジェネレータ作るのはかなり簡単だよ。LL(1)やLALR(1)のパーザジェネレータ 作るのと比べてもかなり簡単。LLやLR系だと文法に対するグローバルな解析が必要になるけど PEGはそういうのしなくていいし。パーザジェネレータじゃなくてパーザコンビネータならもっと簡単に書ける 無名関数に相当する機能がある言語だったら、大体100行程度で基本的な機能を持ったものを作れる 309 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:14:10 ] PEGの利点： ・原理的にyaccとかのLALR(1)より強力なので、yaccでハンドリングするのが難しい文法も簡単に扱える(ことがある) ・レクサとパーザが統合されてるので、Rubyの"#{exp}"みたいな式埋め込み文字列みたいな文法も簡単に扱える 　・Rubyとかではトリッキーな事をしてこの問題を回避している ・アルゴリズムが簡単なので挙動を理解しやすい＝文法をデバッグしやすい（かも） PEGの欠点： ・ナイーブな実装では最悪の場合指数関数時間（だけど、実用上最悪ケースはそんなに起きないと思う） ・メモ化(Packrat)しても、定数係数でLLやLRとかの非バックトラック型のパーザよりは遅い ・Packratだと、状態付きパーザを扱うのが難しい(シンボル表を参照しながらパーズする場合など) ・レクサとパーザが統合されてるので、空白とかの処理がやや面倒 310 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:14:12 ] それはPackratパーザ？ それともバックトラック？ 311 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:15:27 ] >>310 Packratも基本的には、単にナイーブなPEGパーザをメモ化するだけなので、多少手間が増えるくらいで、実装は難しくは無い 312 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:28:07 ] とりあえずLISP系でスマートに実装してみて！ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 313 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:43:41 ] >>312 OK. 1時間くらい待っててくれ 314 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 16:50:54 ] なんかPEG/Packrat詳しい人がいるみたいなので質問させてくれ。 手元のPEGのサンプルは四則計算を解釈していて、いきなりインタプリタとして動くようになっている。 いきなり動かすんじゃなくて構文木構築の段階で動作をとめることはできるんだろうか？ それから途中まで解析した文脈を情報として続く解釈で再利用できるだろうか？ 例えばPythonの文法を考えてもらうとして、 # ***ここから*** if [Expr]: 　　[Sentence] 　　[Sentence] [Sentence] # ***ここまで*** Pythonでは構文の範囲は字下げで表現しているので、 if文の範囲を調べるのに字下げの数を数えないといけない。 どうやって解釈させたらいいのかわからなくて戸惑っているところなんだが。 315 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:21:20 ] そのサンプルは、構文木を作ってから四則演算を実行してるんじゃなくて、 いきなり構文を解析しながら四則演算をしてるんじゃなかろうかという気がするが。 オフサイドルールとかはPEGの鬼門だということかと。 確か原論文では、それを理由にHaskellはムズいとして、Javaのパーザを 実装していた。 多分さがせば解決方法が出てる論文もあるだろうと思うのだけど。 パーザを状態付きにする方法は原論文にある。 316 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:56:21 ] >>309 > 定数係数で この言葉遣いはちょっと変なのでは? >>314 字下げ処理はレキサの仕事と割りきってしまえばそれほど難しくはないでしょ。 先読みして{と}に相当するものに変換できるから。 317 名前：313 mailto:sage [2009/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 mailto:sage [2009/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 mailto:sage [2009/08/04(火) 18:28:52 ] Pythonのインデントルールみたいなのは、レキサがインデント処理する事が前提だから、PEG/Packrat で処理する場合でも、レキサを別に用意した方が書きやすいと思う。レキサがあったらPEGじゃないというわけ じゃないので別に構わないはず(基本単位が文字の代わりにトークンになるだけ)。 320 名前：デフォルトの名無しさん mailto:sage [2009/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 mailto:sage [2009/08/04(火) 19:34:21 ] >>320 たぶんそれであってる。まあ、これだけだと構文エラー時のエラーメッセージ 表示とかどうしようも無いし、実用的にしようと思うと、色々付け足す必要があるけど、 コアの部分はこれくらい簡単だということで。 322 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 23:05:50 ] みんな論文みながら作ってるの？ どうやってpackrat実装すればいいかよくわからん 323 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 23:21:12 ] 21世紀…人類はいまだに左再帰問題を克服できずにいた 324 名前：313 mailto:sage [2009/08/05(水) 00:55:09 ] >>322 一応、自分が作ったときは論文参考にしたけど、基本的にナイーブなPEGパーザ＋メモ化に過ぎ無いから それさえわかっていれば、自力で実装することもできると想う。ヒントとして、上で書いたSchemeによる パーザコンビネータで、各非終端記号の解析結果をメモ化するにはどうすればいいか考えてみて。 Rats!とか高度な最適化してる奴はまあソース読むしかないと思うけど。 325 名前：デフォルトの名無しさん mailto:sage [2009/08/05(水) 01:16:54 ] 左再帰の論文もあったような。 326 名前：デフォルトの名無しさん mailto:sage [2009/08/05(水) 02:07:47 ] これのことかな。 Packrat Parsers Can Support Left Recursion (PEPM 2008) Alessandro Warth, James R. Douglass, and Todd Millstein www.tinlizzie.org/~awarth/papers/pepm08.pdf 327 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 18:40:53 ] COBOLインタープリタを作ろうと思ったが挫折。 制定されているキーワードの数が尋常じゃない。 商用COBOLコンパイラを作っているメーカーの人はマジ天才。 328 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 19:51:58 ] 何でそんなものを作ろうと思ったんだｗ 329 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 03:42:55 ] COBOLかっこいいじゃん。大文字で。 Cを使える人はいっぱいいるけど、COBOLはそうはいない。 だからこっそり開発して職場のヒーローになろうと思ってね。 でも道は遠かった・・・使うのと作るのとは別物なのだ。 330 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 09:26:31 ] >>327 > 制定されているキーワードの数が尋常じゃない。 何のためにパーサジェネレータがあるんだか まあ、BNF 打ち込むだけで疲労困憊ってのはあるかもしれんが… 331 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 09:32:18 ] 大文字使いたいだけならマクロでも使えばいいじゃん 332 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 10:31:58 ] >>330 やっぱ疲労困憊ら？(静岡弁で) 333 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 11:53:19 ] >COBOL ほとんどは命令の名前なんだから、Identificationのレベルで区切って、 命令の判別はあとの段階にまわした方が簡単になるんじゃない？ あとはまあ、フリーソフトのCOBOLの処理系なんて昔ならともかく今ならいくつもあるんだし、作らないという手も。 334 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 15:03:20 ] ゲームのNPCとかにスクリプトを使いたいんだけど 参考になるサイト教えて、lexとかyaccとか難しいのはいらない 335 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 15:32:59 ] >>334 とっつきは悪いかもしれないけど、yacc&lexを使った方が 結局は落だと思うよ。 336 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 16:35:21 ] >>334 オープンソースのスクリプトの処理系を組み込んだ方が普通は楽。 オレはそれにシナリオ記述用の独自形式のスクリプトと２種類用意しているが。 337 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 17:11:04 ] >>334 ゲームの性質（リアルタイムとかアドベンチャーとか）にもよるけど ゼロから勉強しなきゃいけないならYaccとかbisonとかの支援受けるのは悪くないと思うよ 組み込みでスクリプトをその場解析する必要があるならLRのパーサを裸で実装したマイクロPlan（1970年代のbitの記事）とかもあるからそういうレガシーなものもいいかもしれない（これは中間コードＶＭとしても結構興味深い） っというわけで334がどういうものを欲しているかによって回答が異なるのだな 338 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 21:00:13 ] luaは洋ゲーで良く使われてる 339 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 21:21:39 ] >>337 マイクロPlan懐かしすぎ 臨時増刊捨てなきゃよかった 340 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 23:00:14 ] >>339 同じく後悔してる 他にもmicro StarTrekやTinyBASICのソースもあったんだよな >>334 ゼロから勉強するつもりで、もし入手できるなら「翻訳系構成法序論」がお勧め。 えらく堅苦しい題名だけど、たった136ページで翻訳系(コンパイラ)から 翻訳器生成系(yaccのようなコンパイラコンパイラ)まで作成方法が解説してある。 言語はPascal系なModula-2だけど、難解なアルゴリズムではないから、 C/Javaなどに慣れていれば読解に問題はないと思う。 あと、自前で言語処理系を作らないつもりなら、Tcl/Ruby/Pytonみたいな 汎用スクリプト言語をゲームアプリの中に「埋め込む」ことも検討できる。 ゲーム専用のスクリプトエンジンについては、よく分からんなぁ。 341 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 01:44:52 ] 老婆心だが、Tcl/Ruby/Python のうち、Rubyを組み込むのは やめたほうがいいと忠告しておこう Tclはもともと組み込みのための処理系だし、Pythonもある程度 考えてあって商用も含めて実績も多い。 R（以下略 342 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 01:51:34 ] PL/0まじおすすめ 許されるのは小学生までだけど 343 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 01:59:01 ] >>334 tclかluaを使うことにして、公式ドキュメントを。 344 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 02:48:09 ] >>334 あとはまあ、NPCの台詞や動き程度なら、 イベントの発生条件とイベントの内容をデータとして書ければいいわけだから、 スクリプト言語を使うまでもなく、 XMLやYAMLなどで宣言的データとして書く方法もある。 ちょうど、同じようなものを自分で作ろうとしているところ。 345 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 03:15:15 ] >>341 スレ違いの質問で悪いが、続きを聞かせてくれ。 実際、Pythonを組み込んだオプソだけど高機能な3Dソフトを 知っているし、それに対してRubyはvimくらいしか実績を知らない。 ただ、Rubyの組み込みに何か技術的に致命的な欠陥があったりするのか、 あるいは、それほどPythonが組み込みに優れているのかまでは分からないんだ。 それとも単に>>341の印象で語ってるのか？ 346 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 03:35:11 ] >>345 341ではないが、代わりに答えてみよう。 Rubyでは処理系そのものをライブラリの形で差し替えたり、 あるいはJavaや.NETの枠組みで処理系そのものを再実装したりの試みは広く行われているが、 Rubyを組み込みスクリプトとして使用する例はオレもRPGツクールXPくらいしかしらない。 あまりその辺の分野は活発ではないような気がする。 いい加減スレ違いだから、これ以上の話はRubyのスレに行ってくれ。 347 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 10:55:31 ] 独自に実装かつ、yacc&lexは難しいと言うなら、LISPかForthがいいんじゃね？ LISPはよく見るから、あえてForthでやってみてくれ。 348 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 13:30:18 ] >>345 ruby は GC というかメモリ管理まわりの兼ね合いで 組み込みがかなり面倒、という話を聞いたことがある 349 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 14:10:04 ] スレチだけど、言語実装の話でもあるので、ちょっとRubyの話を続けると、 組み込みに向かないのは、evalがあるのが大きいと思う。 そのせいで、パーサとVMが独立できないので、言語まるごと組み込む必要が あるのが大変なんじゃないかと。 1.9でその辺は変わったみたいだけど。 350 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 14:27:07 ] 行の1文字目で処理を分ける程度でいいんじゃね？ 351 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 14:33:22 ] １文字で思い出したけど、変数名が１文字の場合はハッシュ使わないで ２６個のテーブルってのどう？ 352 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 14:41:29 ] いつの時代のＢＡＳＩＣだよ 353 名前：デフォルトの名無しさん [2009/08/13(木) 15:08:53 ] Rubyの話をもちっと聞かせてくれ。 俺も拡張機能用にPythonを組み込んだアプリは良く見るが Rubyを組み込んだアプリは見たことが無い。 これは単にRubyが歴史が浅いからなのか、それともRubyが組み込みで使えない深い理由があるのか？ 354 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 15:33:13 ] >>352 難読化したjQueryとかじゃね？ 355 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 16:00:40 ] じゃあこのスレっぽく話を広げようか 俺341だけど、言いだしっぺっぽいので まず指摘されてたけど、メモリ管理の点で、1.8時代はネイティブスレッドとは 破滅的に相性が悪かったし、ウィンドウシステム・３D・DirexX関係も 相性はあまりよくない。 それに対してPythonは参照カウントとマーク＆スイープの組み合わせで、 マーク＆スイープもおとなしいタイプ。 参照カウントってのはちょっとダサいが、質実剛健だしその点では好感。 あと、これは俺の想像だけど、Pythonの作者は、PythonからCを使うってのと CからPythonを使うってのを対称的で対等なものとして考えている雰囲気があるし、 技術的に変なこだわりはなくて、いろんなところに配慮しながら無難な実装をしてる。 Rubyは実装技術オタクのMatzが作ったので、変なところでこだわってたり 無駄に離れ業やってたりしてタチが悪い ただし、Rubyは将来的にはマルチVMも可能にしようという方向で動いてるようだから そこらへんは変わってくるかもしれない 356 名前：デフォルトの名無しさん mailto:sage [2009/08/13(木) 20:56:15 ] とりあえず Google SketchUp が Ruby 組み込みだったはず。 357 名前：デフォルトの名無しさん [2009/08/14(金) 01:20:18 ] Q. 64bitプログラムとは、どのような文を書くといいのですか A. コンパイラが64bitコンパイルできるなら何でも64bitプログラムになります 心底「ダメだこのバカ」と思った 358 名前：デフォルトの名無しさん mailto:sage [2009/08/14(金) 09:35:58 ] >>357 つぶやきはtwitterで 359 名前：デフォルトの名無しさん mailto:sage [2009/08/14(金) 11:41:34 ] >>357 スレ違い 64bitのソフトウェアってどうやって作るの？ pc12.2ch.net/test/read.cgi/tech/1170481037/ そのセリフの人物によっては ハズレの外注を引いたときの対応 2人目 pc11.2ch.net/test/read.cgi/prog/1147161173/ 【まるで】使えない新人 0x1C pc11.2ch.net/test/read.cgi/prog/1249835909/ など 360 名前：デフォルトの名無しさん [2009/08/14(金) 21:52:07 ] トークンという物について質問させてください。 例えば s = "ABC"; という文があった場合トークンは、 1. s 2. = 3. " 4. ABC 5. " 6. ; でいいのでしょうか？ とくに文字列が "ABC" で1つのトークンなのか "とABCと"で3つのトークンなのかがわかりません。 361 名前：デフォルトの名無しさん mailto:sage [2009/08/14(金) 21:59:32 ] s = "ABC" ; と分けるのが一般的かと思います 362 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 00:06:09 ] Forthは"が単独トークンになるね。 363 名前：345 mailto:sage [2009/08/15(土) 00:07:23 ] スクリプトエンジンのスレだから、 「組み込み用途における技術的観点での比較」に絞ってレスする。 宗教戦争を煽る気はない。 >>346 >あまりその辺の分野は活発ではないような気がする。 Rubyは組み込みの実績が少ないし活動が活発ではないという理由かな。 それは技術的な理由からは外れている気がする。そうなった理由(背景)がこのスレの主題。 >>349 >そのせいで、パーサとVMが独立できないので、言語まるごと組み込む必要が >あるのが大変なんじゃないかと。 Rubyが言語まるごと(パーザ+VM)組み込む必要があるのは事実。 ただし、個人的な感覚として、アプリケーションにスクリプトを組み込む目的の多くは、 ユーザによるアプリケーション機能の自由な拡張(スクリプティング)なのだから、 まるごと実装は欠点にはならないと思う。(JavaVMのようなコンパイラ系は別) (長いので続く) 364 名前：345 mailto:sage [2009/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 mailto:sage [2009/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 mailto:sage [2009/08/15(土) 00:18:02 ] (>>365の続き) あと(技術的な観点ではないけど)付け加えるとすれば、 Pythonは公式文書として組み込み方法が解説されているのに対して、 Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が 唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差異が、 組み込み実績という結果に大きく影響していると思われる。 これだけだと何の事か分かりずらいと思うので、最後に具体的なアドバイスをまとめる。 - RubyプログラマはRuby組み込みで、PythonプログラマはPython組み込みを選ぶのが楽 - ただし、ネイティブスレッドが前提なアプリケーションであれば、Pythonしかない - どちらも知らない人は、(解説文書が整備されている)Phyton組み込みが無難な選択(=お勧め) - ただし、言語の選択は、システム全体を見渡してから判断すべき(解説文書の有無だけで 　言語を選択すると、本末転倒になる恐れがある(木を見て森を見ず)) 長文/連投のスレ汚し、失礼しますた。 367 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 00:43:35 ] 元々の話のゲームのスクリプト用途とかなら 既に挙げられてはいるけど lua みたいな 最初から組み込み用に作られたものを使うのが無難じゃないかな 変に難しいこと考えなくても楽に組み込めるし 368 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 00:53:25 ] 長過ぎて読んでないが、 結局Rubyを無理やり組み込む人はいないと 369 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 00:53:49 ] これだけ長文でレスしたくせに、中身がほとんど無いじゃないか。 スレ違いをいちいち長ったらしく指摘しなくていいからもっと短くまとめろよ。 > あと(技術的な観点ではないけど)付け加えるとすれば、 > Pythonは公式文書として組み込み方法が解説されているのに対して、 > Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が > 唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差 > 異が、組み込み実績という結果に大きく影響していると思われる。 付け加えじゃなくて、ここが一番重要なところだろ。 370 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 00:58:42 ] 機能的にはschemeやjavascript辺りのサブセットがVMで動けば十分 バランスが取れたのがlua 実際にスクリプトを書かせる対象を想定しないとな 371 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 01:04:13 ] >>366 まず、俺の主観が入っているってのはその通り。その点はすんまそん てかあまり深く考えずに書き込んだけど、363氏の説明の方がほとんど 正しいと思います。 いくつか書きたいのは、 PythonのGCは停止時間（いわゆるレスポンス）が悪くない。 循環参照を解消するために定期的に マーク＆スイープする必要があるけど、そのタイミングは制御できる。 たとえばゲームでいえばシーン暗転の時にやるとか。 Rubyは逆で、楽だけど大味な制御しかできない 以前に256倍網道編でarton氏がpure rubyでゲーム作ってたけど、 実際実行すると結構カクカクだった ついでにいうとCから使ってるとファイナライザが欲しくなるが、 CPythonならスコープはずれたら解放されることが（個別実装の仕様として） 保証されるので楽。 これらが決定的な利点・欠点かどうかは状況に依存するね。もちろん あと実装じゃなくて完全にスレチだけど、ライセンスが違うのと、 （用途によるが）配布の際にバイトコード化可能かいう点もある。 以上で撤収します 372 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 01:40:39 ] forthってGCってあるんだっけ？ あれ？ディクショナリ内にメモリって確保するんだっけ？ 373 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 01:48:28 ] 組み込み用スクリプトのインタプリタとライブラリのデバッグに時間を掛けたくないよね ゲーム本体よりも大きいと本末転倒だし ソースがせいぜい２〜３ファイル、合計数百行程度、使えるライブラリは関数をテーブルに登録ぐらいが理想か 374 名前：345 mailto:sage [2009/08/15(土) 02:21:05 ] >>371 >まず、俺の主観が入っているってのはその通り。その点はすんまそん こちらこそネチネチ書いてスマンかったです。ただ主観/印象で論議すると 宗教戦争に陥りがちだから、それを避けたかった。分かってくださいませ。 >Rubyは逆で、楽だけど大味な制御しかできない RubyもGCを明示的に起動できますよ。シーン暗転前に起動すればいいと思いますが....。 >実際実行すると結構カクカクだった カクカクになるのは、GCとは別の要因ではないかと思います。 GCが原因なら、(比較的あいた間隔で)実行が固まったように見えるはずですから。 >CPythonならスコープはずれたら解放されることが（個別実装の仕様として） >保証されるので楽。 これは、(Cスタック上に)auto変数としてPythonVMを確保すれば、そのVMと実行環境が まとめて自動的に解放されるということでしょうか？ もし本当なら、(Rubyと比較して)かなりプログラマの負担が減りますね。 あと同一プロセス上でのマルチVM(インタプリタ)も簡単に実現できると思われますし。 >あと実装じゃなくて完全にスレチだけど、ライセンスが違うのと、 Rubyライセンスは、とっても緩やかなものです。Matzは言語オタクだから、 (権利の主張よりも)自分の作品を使ってくれることに喜びを感じてるのだと想像させるほどに。 >（用途によるが）配布の際にバイトコード化可能かいう点もある。 これも、(オプソなプロジェクト以外では)採用を決めかねない大きなPythonの利点ですね。 ソース非公開というニーズは多いと思いますから、>>363の最後の段落は撤回します。 375 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 02:49:20 ] いまさらなんだが既存のスクリプトエンジンを組込む話は 組込み系言語スレがふさわしいと思う。 376 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 03:05:22 ] javascriptはBOTとかのチートツールで使われてる 377 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 03:08:01 ] >>375 でもあそこでpとかrとか言ったら荒れるんだよね 378 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 08:17:18 ] >>355 > 参照カウントってのはちょっとダサいが、質実剛健だしその点では好感。 mark & sweepと併用するやり方は、 どっちをメインにするとしても、極めて有効なやり方だよ。 379 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 09:46:27 ] Rubyは実装として美しくない 最近の高スペックPC当て込んだ バブル言語だろ 380 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 10:16:03 ] Forthは基本的にはライブラリ（辞書）管理もFILOだから、 GCという概念がない。動的なデータ構造も（スタック以外）ないし。 PostScriptは確かスナップショットのようなものを取って、 明示的に指定してそのスナップショット以降に確保されたものを 解放するとかそういう機能がある、と思った。 381 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 11:29:43 ] おれ科学計算系で、3回くらいPythonが組み込まれてるソフトを 触ったことがあるよ。個人的な感想だが、pythonの微妙に面倒臭いところが、 組み込みだと逆にぴったり使いやすいんだわ。説明しづらいけど。 Rubyの自由さは組み込み向けだと正直いらない。 382 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 13:30:14 ] >>363-366 おおむね同意だが、>>349に対するレスはやや違うと思う。 漠然とスクリプトエンジンと題した場合、真っ先に求められるのは 書いたスクリプトをその場で実行できる手軽さであり、 必然的にインタプリタの要件を満たすことになる。 これに現在主流がバイトコンパイル式であることを勘案すると 言語まるごと(パーサ+VM)を組み込むことがほぼ確定になる。 まあオレがオレオレ処理系を作るときはスクリプトのコンパイラは 事実上のジェネレータとして実装して、 生成物は汎用のスクリプトの処理系に渡してしまうから 自作部分は純粋なコンパイラになるわけだが。 開発用にはそれとは別にスクリプトのタイムスタンプを見て 自動的にコンパイル作業を行う機能を追加することになるだろう。 383 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 13:32:25 ] ruby のライセンスは GPL よりは緩いけど 他の組み込み向け言語に比べると だいぶめんどくさい方だと思うけどな まぁライセンス云々はスレ違いだけど 384 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 13:58:23 ] >>382 パーサーの要不要は用途次第かと ゲーム用とかだと開発時は素早く試行錯誤したいが リリース後は基本的にはスクリプトをいじる必要がないので そういう場合パーサーは無駄なので最終的には外せる方が良い 実行環境がプアなものは特に 385 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 14:58:43 ] これが噂の「すり合わせ」というやつか 386 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 17:01:08 ] 生インタプリタも、中間形式分離型も両方ある奴がほしい、という 要望ってこれからも大きいかな？ 今のところメジャーなもので、実現したものってないような気がするけど。 387 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 17:41:29 ] Ruby, Python等のダイナミック言語でパーサを分離するのは無理じゃないか？ 例えばPerlだと、実行せずに静的にパースすることは不可能なわけだし。 ttp://perlmonks.org/?node_id=663393& 388 名前：345 mailto:sage [2009/08/15(土) 18:25:09 ] >>387 Pythonであれば、以下のようなカキコがあるから、 パーザとVMは分離できるように見えるけど、違うの？ Pytonにはevalは存在しないみたいだし(>>349参照) >>371 >（用途によるが）配布の際にバイトコード化可能かいう点もある。 389 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 19:16:11 ] >>380 > Forthは基本的にはライブラリ（辞書）管理もFILOだから、 > GCという概念がない。動的なデータ構造も（スタック以外）ないし。 それは嘘。 FORTHを採用する場合、 後置記法を採用するくらいだから、 非常に小さいインタプリタが必要とされている局面。 だからプアな処理系が多いと言うだけで、 GCをバッチリ実装した処理系はあってもいい。 データがFILOで済むというのも嘘。 辞書に登録したら不必要になる順序はプログラム次第。 390 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 19:56:55 ] まあ誰もスクリプトでFORTHなんか使いたくないからどうでもいいけどなｗ 391 名前：387 mailto:sage [2009/08/15(土) 20:03:53 ] >>388 実際にPythonやRubyでパースが曖昧になるようなケースは知らないが、 evalがあると分離しにくいのは確かだろうね。ちなみにPythonにもevalはある。 392 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 21:33:03 ] そこれりすぷれすよ 393 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 21:35:35 ] Rubyが使われないのは単に実績がないからなんでしょ どんどん使えばいいと思うよ 394 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 21:45:11 ] 組み込みスクリプト用のLispってあるの？ 395 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 21:50:20 ] emacs lisp 396 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 22:02:09 ] Ypsilon 397 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 23:35:53 ] elisp 398 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 23:43:00 ] ruby 399 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 00:05:29 ] >>394 小さな独自Lisp系ならいくらでもあるよ(CLとかSchemeとかの規格準拠じゃなければ8ビット機でだって動くんだもの) 400 名前：345 mailto:sage [2009/08/16(日) 01:27:27 ] >>391 え、Pythonにもevalあるんですか？！うーむ どちらが真実かは、結局は自分で調べなさいということですな。 401 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 01:36:23 ] python -c 'print eval("1+1")' 402 名前：345 mailto:sage [2009/08/16(日) 01:52:09 ] >>401 再現しますた。わざわざありがトン。 403 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 02:37:35 ] >>394 LISPerは自分用のがあるから 他人の糞LISPなんて使わない

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef